Re: [controller-dev] Release Readiness : From SNAPSHOT to Release & Branching recommendations

Muthukumaran Kothandaraman <mkothand@...>

Agreed Madhu. That makes sense. It is a separate thread of discussion.


Muthukumaran (Muthu)

P(existence at t) = 1- 1/P(existence at t-1)

From:        Madhu Venguopal <mavenugo@...>
To:        Muthukumaran Kothandaraman/India/IBM@IBMIN
Cc:        Anees A Shaikh <aashaikh@...>, abhijitk <abhijitk@...>, "<affinity-dev@...>" <affinity-dev@...>, "bgpcep-dev@..." <bgpcep-dev@...>, Chris Wright <chrisw@...>, Colin Dixon <ckd@...>, dev <controller-dev@...>, controller-dev-bounces@..., "david.goldberg" <david.goldberg@...>, "<defense4all-dev@...>" <defense4all-dev@...>, David Meyer <dmm@...>, "Ed Warnicke (eaw)" <eaw@...>, gerag <gerag@...>, Giovanni Meo <gmeo@...>, "integration-dev@..." <integration-dev@...>, konstantinp <KonstantinP@...>, "lispflowmapping-dev@..." <lispflowmapping-dev@...>, Luis Gomez <luis.gomez@...>, "michal.polkorab" <michal.polkorab@...>, "opendove-dev@..." <opendove-dev@...>, "openflowjava-dev-bounces@..." <openflowjava-dev-bounces@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, Ryan Moats <rmoats@...>, rovarga <rovarga@...>, snmp4sdn-dev@..., Suchi Raman <suchi.raman@...>, ttkacik@..., "vtn-dev@..." <vtn-dev@...>, yangtools-dev@..., ylhsieh <ylhsieh@...>
Date:        01/15/2014 03:10 AM
Subject:        Re: [controller-dev] Release Readiness : From SNAPSHOT to Release & Branching recommendations

Hi Muthu,

I forgot to mention in the email that, this recommendation is purely for the Hydrogen release & we will deal with the
details on branch management and versioning post-hydrogen release. There is a huge implication on having multiple
versions of bundle floating around and we need much more stricter recommendations on how to handle such scenarios.
But, since for the Hydrogen release, we are converging on a release bundle, this issue can be postponed for Post-Hydrogen.

To answer your question :
1. Yes. the maven-release-plugin will automatically bump up the SNAPSHOT version from
<major>.<minor>.<micro>-SNAPSHOT  to <major>.<minor>.<micro+1>-SNAPSHOT.

2. Regarding the version changes post-hydrogen and dependencies, I would like to defer the discussion on a different email thread
   and not mix with the Release Readiness & i hope you are okay with that.

There is certainly a bigger implication on the bundle versions, SNAPSHOT, STABLE releases and their dependency trees.
A lot of discussion have to go inside that to have a stabler subsequent Helium release.


On 1/14/14, 3:06 AM, Muthukumaran Kothandaraman wrote:
Hi Madhu,

A couple of quick clarification on future changes

- Soon after the RELEASE version, we would also have the subsequent SNAPSHOT version - I understand that release-plugin provides that discipline - but would we be following the same or there are any changes in ODL process-policy ?

- Would we be avoiding version changes in SNAPSHOT phase in future - the implication in mail-chain here -
 Again, unmistakably, Giovanni provided a mechanism to streamline this :-)  

 But, would we have a policy that during SNAPSHOT phase we do not change module versions in future ?
 Because version-changes during SNAPSHOT phase could help binary dependency flexibility (eg. not all modules could pickup latest versions of their dependencies) but from source-control perspective version-changes do not help.


Muthukumaran (Muthu)
L  : 080-49141730

P(existence at t) = 1- 1/P(existence at t-1)

Madhu Venguopal <mavenugo@...>
dev <controller-dev@...>, yangtools-dev@..., "openflowjava-dev-bounces@..." <openflowjava-dev-bounces@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>, "vtn-dev@..." <vtn-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "opendove-dev@..." <opendove-dev@...>, "<affinity-dev@...>"        <affinity-dev@...>, "<defense4all-dev@...>"        <defense4all-dev@...>, "bgpcep-dev@..." <bgpcep-dev@...>, "lispflowmapping-dev@..." <lispflowmapping-dev@...>, snmp4sdn-dev@..., "Ed Warnicke (eaw)" <eaw@...>, ttkacik@..., abhijitk <abhijitk@...>, "michal.polkorab" <michal.polkorab@...>, Anees A Shaikh <aashaikh@...>, Ryan Moats <rmoats@...>, Suchi Raman <suchi.raman@...>, gerag <gerag@...>, konstantinp <KonstantinP@...>, rovarga <rovarga@...>, "david.goldberg" <david.goldberg@...>, ylhsieh <ylhsieh@...>, "integration-dev@..." <integration-dev@...>, Luis Gomez <luis.gomez@...>, Colin Dixon <ckd@...>, David Meyer <dmm@...>, Chris Wright <chrisw@...>, Giovanni Meo <gmeo@...>
01/14/2014 04:01 PM
[controller-dev] Release Readiness : From SNAPSHOT to Release &        Branching recommendations
Sent by:        

Hi Devs,

Apologies on the long email again. I cant think of any better way to communicate this kind of info.
This email is also updated in wiki

The last step of the development process for the Hydrogen (or any subsequent release) is to move from SNAPSHOT
versions of the bundle to the release version. This release version of the bundles are deemed the stable version.

As per the collective decision during the TSC call, we decided on starting the process of cutting over from SNAPSHOT
to the release version on 01/27 & we expect this process to be complete by 01/28.

If this is the last step and if it is planned on 01/27, why are we discussing about this now ?.
The answer is simple, There are lots of pre-work to be done here and the project owners (& volunteers) should gear up well in advance.

This email will provide the recommendation for cutting-over to the release versions and the subsequent branching strategy.
This is a heavy topic and we have a ton of information to share and discuss.

Short list of Things TODO for Project Owners and Project Volunteers to start working on today (01/14/2014)

0. Finish up the "Release Readiness : Dependency convergence" ASAP.

1. Please review this email from Giovanni Meo :
   Most of it holds even for today. Some info are outdated (but still quite useful to know).

2. Prepare your project for the release (refer to
   1a. Every POM file should have proper <scm> section. Care must be taken to make sure every pom file in a project must carry the exact <scm> section.
   1b. Add maven-release-plugin to the plugin management section of your project (refer to opendaylight/commons/opendaylight/pom.xml in the above gerrit : 978).
   1c. If not already present, add a POM file to the root of your project from where we can execute the release operations.

3. We will be using maven-release-plugin. Hence please review :

4. Thank god, we have Giovanni amongst us :-), he already went through the painful process of releasing artifacts from the controller project and
    the jenkins jobs used for that (in September'2013) are as follows :
    4a. Prepare-only :
    4b. Final Publish :
    Please review these & ask any questions you might have. Dont copy it yet to your projects.

5. Based on the Dependency tree evaluation, the only incorrect project dependencies was identified on controller depending directly on bgpcep.
   We have to remove this dependency from the controller project.

6. It is recommended to start with the 1.0.0 as the release/branch version. If we agree on 1.0.0 as the release/branch name, then the version of the
   parent root pom must be set to 1.0.0-SNAPSHOT, which will be automatically used by the jenkins job.

List of things ToDo on 01/27 & 01/28

0. Though the following activities are per-project related, it is recommended to do this as a group with representatives from all the projects present.

1. Based on the dependency tree evaluation, we have to perform the release process in the following sequence
   - yangtools
   - controller
   - openflowjava , ovsdb, opendove, vtn, affinity, bgpcep, lispflowmapping, snmp4sdn, defense4all (all these projects can be done in parallel)
   - openflowplugin (after openflowjava).

2. Any inter-project SNAPSHOT version dependencies must be changed to the RELEASE version dependency. For example, Controller project is
   dependent on Yangtools SNAPSHOT, it must be changed to the yangtools's release version & so on and so forth and commit the changes to your repo.

3. In each project, we have to copy both the Prepare-only & Final-Publish jenkins jobs from the controller project & adjust it to per-project configurations.

4. Execute the prepare-only jenkins job and make sure all the issues are resolved and we get to a successful execution.

5. Execute the Final-publish job (bulk-release) on your project that will publish the artifact to the nexus repo.

6. In Step4, the maven-release-plugin would also drop a tag in the GIT repo to mark the exact release point. We can either manually create a branch on
   each of the project with a Branch version (please note that this Branch version is Nothing to do with the artifact versions, as they are different in each bundle)
   or automate the branch creation on the jenkins job.

Ofcourse, there are tons of detailed information available on all these. Please dont take this lightly. Tons of stuffs to do in getting
the release out & hence your attention to this is highly appreciated.

controller-dev mailing list


Join { to automatically receive all group messages.