Project

General

Profile

Actions

CDM Release, Versioning & Branch Policy

Other conventions and policies are found in the CDM Library Development Resources

All cdm product releases are tagged with a version number which consists of multiple parts:

<major release>.<minor release>.<patch level>

The <major release>.<minor release> do not really need to be explained here since the concept of these is commonly known and understood.

These two numbers are derived from ${project.version} which refers to the x.x of the poms.

For general information on Versioning schemes please refer to see http://en.wikipedia.org/wiki/Software_versioning#Software_Versioning_schemes or http://de.wikipedia.org/wiki/Versionsnummer (in German)

<patch level> starts for a specific version with 0 and is increased by 1 every time we release a new bug fix of version x.x. this number is derived from .${project.patchversion} (maybe I should change this portperty name to project.patchlevel

The patch level is also reflected in the git repository since we decided on the following release branch policy:

  • for a <major release>.<minor release> a new branch is created initially

  • every time a bug fix release is created the latest branch is again branched

So we end up with a branch tree like:

 BRANCH-cdmlib-2.3
    BRANCH-cdmlib-2.3.1
      BRANCH-cdmlib-2.3.2
        BRANCH-cdmlib-2.3.3
BRANCH-cdmlib-3.3
    BRANCH-cdmlib-3.3.1

The <revision number> is used to distinguish between the different builds of a release branch.

All releases, also those downloadable by end users, will be tagged by the full version string. The following scheme illustrates the release process in the context of the branches in the source repository:

 BRANCH-cdmlib-2.3               x---> release BRANCH-cdmlib-2.3.0.r8789
 |                               x---> release BRANCH-cdmlib-2.3.0.r8876
 +-BRANCH-cdmlib-2.3.1           x---> release BRANCH-cdmlib-2.3.1.r8987
    |                            x---> release BRANCH-cdmlib-2.3.1.r9001
    |                            x---> release BRANCH-cdmlib-2.3.1.r9023
    +-BRANCH-cdmlib-2.3.2        x---> release BRANCH-cdmlib-2.3.2.r9045
      +-BRANCH-cdmlib-2.3.3      x---> release BRANCH-cdmlib-2.3.3.r9670
BRANCH-cdmlib-3.3                x---> release BRANCH-cdmlib-3.3.0.r9011
  +-BRANCH-cdmlib-3.3.1          x---> release BRANCH-cdmlib-3.3.1.r9033

How to deal with tickets under review

Usually when a ticket is solved its status is set to 'reviewing' and it is handled to another person to review this ticket.

The reviewer will close the ticket once s/he tests and confirms that it has been solved. Once the ticket is closed it occurs under the next release milestone on our road-map page: Release_Notes

If the ticket can not be closed it should be returned to the original assigne with status Feedback .

Before a release all tickets should be closed or moved to another milestone/target version. In some cases a ticket can only be finally closed immediately after the release. In this case it can be kept in the current milestone with an apporpriate comment.

Updated by Andreas Müller about 1 year ago · 12 revisions