Release Management

From stoney cloud
Jump to: navigation, search

Release Cycles

Each release cycle should follow this pattern:

  1. Development (2 - 4 Weeks): During this phase, new functionalities are developed.
  2. Testing and bug fixing (1 - 2 Weeks): This gives time for the users to test and the time bug fixing and a quick retest.


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:

  1. Trunk (development): Master branch, normally without name tags, for testing reasons we set tags: v0.5.0_pre1
  2. 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
  3. 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


Source Code Organization

All stoney cloud related source code is located on GitHub under To avoid clashes with over projects, every repository has the default prefix stoney-.

Some operating system related examples:

The main framework called stoney core, which is responsible for shared functionality (like user management, rights and roles).

Then we have the Self-Service Modules with stoney backup as an example. This Self-Service Module provides an on-line backup service for desktops, servers and virtual machines.

See the Modularisation page for further details.

Committing / Git Workflow

We follow the Git branching model according to:

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 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 frisby.js


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