Difference between revisions of "Release Management"
[unchecked revision] | [unchecked revision] |
(→Development Procedure) |
(→Source Code Organization) |
||
Line 40: | Line 40: | ||
See the [[Modularisation]] page for details. | See the [[Modularisation]] page for details. | ||
+ | <s> | ||
Every such component-directory contains the following sub-structure: | Every such component-directory contains the following sub-structure: | ||
Line 58: | Line 59: | ||
Disadvantage: | Disadvantage: | ||
* harder to make a complete release (requires updating the references) | * harder to make a complete release (requires updating the references) | ||
+ | </s> | ||
== Committing == | == Committing == |
Revision as of 08:56, 16 October 2013
Contents
Release Cycles
Each release cycle should follow this pattern:
- Development (2 - 4 Weeks): During this phase, new functionalities are developed.
- Feature Freeze (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.
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, ...).
Development Procedure
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 stable version will be released at the earliest when all features and goals specified for this stable version are implemented/reached.
Development
Source Code Organization
Every 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.
Every such component-directory contains the following sub-structure:
- trunk
- tags
- branches
For every release of a component a tag is created in /tags
Development is primarily done in /trunk
. 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)
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 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