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>.r<revision number>

The . 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 or (in German)

**** starts fro 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 . 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:


The **** 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


The reviewer will close the ticket once he test and

confirms that it has been solved. Once the ticket is closed it

occurs under the next release milestone on our road-map page:

But we are often facing a situation in which tickets have

been solved three or more months ago but these tickets are

still waiting to to be reviewed, and thus the do not occur jet

in the release history even if the code is already released.

So history of release milestones on the road map no longer

really reflects the work that has been done in the code, it

partially rather is a history of when reviews have been done.

I guess this is not what a release roadmap is meant to be.

Latest status of the discussion on this:

Exclusively developing in a branch and reintegrating when the review is done would be too time consuming. We may end up needing a 're-integration master' to keep track of the reviews.

I think we should be fine with making the review tickets are as visible as possible. Some ideas for this are,

  1. From Lorna's suggestion, add an expected time line for the review into the ticket.

  2. Create a new 'tickets-under-review' only view in TRAC, to get a quick overview.

  3. Make sure that we retain tickets that are not yet reviewed on the release page with a special flag saying that it is still under review.

Also, (after discussion with AK) I think we should still release if the ticket is not reviewed, because this would involve last minute rollback of updates.

Updated by Katja Luther 8 months ago · 8 revisions