Each release cycle should follow this pattern:
# '''Development''' (2 - 4 Weeks): During this phase, new functionalities are developed.
# '''Feature FreezeTesting and bug fixing''' (1 - 2 Weeks): This gives time for the users to test and the time bug fixing and a quick retest.# '''Code Freeze''' (1 - 2 Weeks): This is a late freeze to avoid sudden last-minute accidents which could risk the stability that should have been reached at this point. No source code changes are allowed without two approvals from the release team, but translation and documentation should continue. Simple build fixes are, of course, allowed without asking.
= Versions Versioning =[http://semver.org/ Semantic Versioning]:Given a version number MAJOR.MINOR.PATCH, increment the:* MAJOR version when you make incompatible API changes,* MINOR version when you add functionality in a backwards-compatible manner, and* PATCH version when you make backwards-compatible bug fixes. Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. * <s>Scheme: major.minor.patch, example: <code>1.2.3</code>.</s>* <s>Odd minor version numbers denote development/unstable branches. For example, stoney cloud 0.8.x is considered stable, while stoney cloud 0.9.x is considered development/unstable.</s>
* New features are added to unstable/development versions only.
* We have separate version numbers for the separate components (installer, online-backup, ldap-schemas, ...).
== Development Procedure ==This results in the following We start with '''0.1.0''' for 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'''0.* A stable version will be released at the earliest when all features and goals specified 2.0''' for this first stable version are implemented/reachedrelease.
= Development Procedure === Source Code Organization ==We have a minimum of two branches:Every module has # Trunk (development): Master branch, normally without name tags, for testing reasons we set tags: v0.5.0_pre1# Branch 1 to N (stable branch(es) for bug fixing): v0.2, the tag for a separate GitHub git repository containing release would be: v0.2.1 to v0.2.N# Branch 2 (second stable branch for bug fixing): v0.4, the following sub-structuretag for a release would be:v0.4.1 to v0.4.N
GitHub:
* Form follows function: we choose the functionality name (so we are backwards compatible)
* Modules are collected in one repository (create a skeleton module as an example):
** Data (LDAP)
** API (PHP)
** Web Interface (PHP, uses API)
** Provisioning (Perl, ...)
** Tests (GUI, Unit-Tests, ...)
See This results in the following development procedure:* Features are scheduled on the individual module [[Modularisation:Category:Roadmap|roadmap]] page 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 detailsthis version are implemented and tested.
Every such component-directory contains the following sub-structureTBD:Describe stable and unstable in more detail
* trunk= Development =* tags== Source Code Organization ==* branchesAll stoney cloud related source code is located on GitHub under https://github.com/stoney-cloud. To avoid clashes with over projects, every repository has the default prefix '''stoney-'''.
For every release of a component a tag is created in <code>Some operating system related examples:* https:/tags</code>github.com/stoney-cloud/stoney-gentoo-overlay* https://github.com/stoney-cloud/stoney-gentoo-portage
Development The main framework called [[:Category:stoney core|stoney core]], which is primarily done in <code>responsible for shared functionality (like user management, rights and roles).* https:/trunk</code>github. Branches are created either for maintaining a specific minorcom/stoney-version of the package or for developing new features cloud/stoney-core* https://github.com/stoney-cloud/stoney-core/api (at developers discretionREST API)* https://github.com/stoney-cloud/stoney-core/cli (Command Line Interface)* https://github.com/stoney-cloud/stoney-core/web (Ajax based web interface)
For doing a complete Then we have the [[:Category:Self-Service Modules|Self-Service Modules]] with [[:Category:stoney cloud releasebackup|stoney backup]] as an example. This Self-Service Module provides an on-line backup service for desktops, a new branchservers and virtual machines.* https:/tag is created in the component /github.com/stoney-cloud/stoney-backup* https://github.com/stoney-cloud/stoney-backup/api (REST '''a'''pplication '''p'''rogramming '''i'''nterface)* https://github.com/stoney -cloud/stoney-backup/cli ('' which contains git repository references '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 the corresponding tagsprovision services)* https:/branches of the other components/github.com/stoney-cloud/stoney-backup/web (Ajax based web interface)
Advantage:* clean separation (of release cycles) between components* easier branching on a per-component basisSee the [[Modularisation]] page for further details.
Disadvantage:== Committing / Git Workflow ==* harder We follow the Git branching model according to make : http://nvie.com/posts/a complete release (requires updating the references)-successful-git-branching-model/
== 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 of 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 ==