EDIT

# CDM Release, Versioning & Branch Policy

Other conventions and policies are found in the [[CdmLibraryDev#ConventionsPolicyies|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 **<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 <project><version>x.x</version> 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 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 svn 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 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:

http://dev.e-taxonomy.eu/trac/wiki/CdmPlatformRoadmap

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:

I think the idea of 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.

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

1. 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.