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 - https://lists.opendaylight.org/pipermail/controller-dev/2013-December/002312.html
  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.

Regards

Muthukumaran (Muthu)
L  : 080-49141730

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



From:        Madhu Venguopal <mavenugo@...>
To:        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@...>
Date:        01/14/2014 04:01 PM
Subject:        [controller-dev] Release Readiness : From SNAPSHOT to Release &        Branching recommendations
Sent by:        controller-dev-bounces@...

---

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 https://wiki.opendaylight.org/view/Simultaneous_Release:Simultaneous_Release_Plan_2014:ReleaseRecommendations.

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.
    (https://wiki.opendaylight.org/view/Simultaneous_Release:Simultaneous_Release_Plan_2014:DependencyConvergence)

1. Please review this email from Giovanni Meo : https://lists.opendaylight.org/pipermail/controller-dev/2013-August/001042.html
    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 https://git.opendaylight.org/gerrit/#/c/978/).
    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 : http://maven.apache.org/maven-release/maven-release-plugin/index.html

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 : https://jenkins.opendaylight.org/controller/job/controller-bulk-release-prepare-only/configure.
     4b. Final Publish : https://jenkins.opendaylight.org/controller/job/controller-bulk-release/
     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.

Thanks,
-Madhu_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev