Release Management
Contents
Release Cycles
Each release cycle should follow this pattern:
- Development (2 - 4 Weeks): During this phase, new functionalities are developed.
- Testing and bug fixing (1 - 2 Weeks): This gives time for the users to test and the time bug fixing and a quick retest.
Versioning
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.
-
Scheme: major.minor.patch, example:1.2.3. -
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. - New features are added to unstable/development versions only.
- 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
We have a minimum of two branches:
- 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 release would be: v0.2.1 to v0.2.N
- Branch 2 (second stable branch for bug fixing): v0.4, the tag for a release would be: v0.4.1 to v0.4.N
This results in the following development procedure:
- Features are scheduled on the individual module 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
We have the stoney cloud related repositories like installer, node-integration, ... These we keep as is (for the moment).
The web interface consists a bunch of modules. Each module has a separate GitHub git repository containing the following sub-structure:
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 the Modularisation page for details.
All 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-.
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.
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.
Bug-Reporting/-Workflow
Bugs are to be reported on the modules issue tracker on GitHub.
Ideally we have someone who acts as the Bug-Wrangler. His tasks are:
- go over unassigned bugs and properly assign them (since we can't expect users to properly assign bugs)
- discover and close duplicated, invalid or otherwise inappropriate bugs (so the Bug-Wrangler must have search-fu)
- request more information from the user if necessary (like the version of involved components, canned responses can be used/saved in the GitHub issue tracker for that purpose)
- request time estimates from developers
- kick developers and testers and make sure the issue-list stays short (therefore it would make sense if it's someone from stepping stone GmbH)
- manage the priority of bugs if necessary
