* We have separate version numbers for the separate components (installer, online-backup, ldap-schemas, ...).
We start with '''0.1.0''' for development and '''0.2.0''' for first stable release.
= Development Procedure =
* Features are scheduled on the individual module [[:Category:Roadmap|roadmap]] pages for implementation in specific future stable versions and are implemented (and tested) in development versions.
* A new major version will be released, when all features and goals specified for this version are implemented and tested.
TBD: Describe stable and unstable in more detail
= Development =
== Source Code Organization ==
Every module has a separate All stoney cloud related source code is located on GitHub git under https://github.com/stoney-cloud. To avoid clashes with over projects, every repository containing has the following subdefault prefix '''stoney-structure:'''.
GitHubSome operating system related examples:* Form follows functionhttps: we choose the functionality name (so we are backwards compatible)//github.com/stoney-cloud/stoney-gentoo-overlay* Modules are collected in one repository (create a skeleton module as an example)https:** Data (LDAP)** API (PHP)** Web Interface (PHP, uses API)** Provisioning (Perl, //github...)** Tests (GUI, Unitcom/stoney-Tests, ...)cloud/stoney-gentoo-portage
See the The main framework called [[Modularisation:Category:stoney core|stoney core]] page , which is responsible for detailsshared functionality (like user management, rights and roles).* https://github.com/stoney-cloud/stoney-core* https://github.com/stoney-cloud/stoney-core/api (REST API)* https://github.com/stoney-cloud/stoney-core/cli (Command Line Interface)* https://github.com/stoney-cloud/stoney-core/web (Ajax based web interface)
<s>Then we have the [[:Category:Self-Service Modules|Self-Service Modules]] with [[:Category:stoney backup|stoney backup]] as an example. This Self-Service Module provides an on-line backup service for desktops, servers and virtual machines.Every such component* https://github.com/stoney-directory contains the following subcloud/stoney-structurebackup* https://github.com/stoney-cloud/stoney-backup/api (REST '''a'''pplication '''p'''rogramming '''i'''nterface)* https://github.com/stoney-cloud/stoney-backup/cli ('''c'''ommand '''l'''ine '''i'''nterface)* https://github.com/stoney-cloud/stoney-backup/helpers (helper scripts and programmes)* https://github.com/stoney-cloud/stoney-backup/provisioning (scripts and programmes to provision services)* https://github.com/stoney-cloud/stoney-backup/web (Ajax based web interface)
* trunk* tags* branchesSee the [[Modularisation]] page for further details.
For every release of a component a tag is created in <code>== Committing /tags<Git Workflow ==We follow the Git branching model according to: http://nvie.com/posts/a-successful-git-branching-model/code>
Development is primarily done in <code>/trunk</code>. Branches are created either for maintaining a specific minor-version of the package or for developing new features (at developers discretion).
For doing a complete stoney cloud release, a new branch/tag is created in the component ''stoney cloud'' which contains git repository references to the corresponding tags/branches of the other components.
Advantage:
* clean separation (of release cycles) between components
* easier branching on a per-component basis
Disadvantage:
* harder to make a complete release (requires updating the references)
</s>
== Committing ==
Each change-set in the git repository (and thus each commit) ideally contains only one concise and consistent change.
The commit-message precisely describes the change. If the change is in respond to a bug-report or feature-request, the number of the bug-report or feature-request is included.
== Scrum Labels ==
* '''Not Started''': not yet assigned to or accepted by any member.
* '''Assigned''': being assigned to or accepted by a member.
* '''In Progress''': being implemented.
* '''To Verify''': implementation done and now it is time for testing/verifying.
* '''Done''': ticket is verified.
== Testing ==
Testing is done in a clean test environment and '''not''' in a developer environment.
This means: all changes have to be committed to the git repository first and checked out from there in the test environment for proper testing.
* tests can be run on different levels
** framework-level (symfony/php unit tests)
** API-level:
*** JSON Schema compliance
*** client-test via [http://frisbyjs.com/ frisby.js]
== Bug-Reporting/-Workflow ==