toggle quoted message
Show quoted text
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
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
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
A couple of quick clarification
- Soon after the RELEASE version,
would also have the subsequent SNAPSHOT version - I understand
provides that discipline - but would we be following the same or
are any changes in ODL process-policy ?
- Would we be avoiding version
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
during SNAPSHOT phase we do not change module versions in future
Because version-changes during
SNAPSHOT phase could help binary dependency flexibility (eg. not
could pickup latest versions of their dependencies) but from
perspective version-changes do not help.
L : 080-49141730
P(existence at t) = 1- 1/P(existence at t-1)
"Ed Warnicke (eaw)" <eaw@...>, ttkacik@...,
abhijitk <abhijitk@...>, "michal.polkorab"
Anees A Shaikh <aashaikh@...>, Ryan Moats
Suchi Raman <suchi.raman@...>, gerag
konstantinp <KonstantinP@...>, rovarga
"david.goldberg" <david.goldberg@...>, ylhsieh
<integration-dev@...>, Luis Gomez
Colin Dixon <ckd@...>, David Meyer
Chris Wright <chrisw@...>, Giovanni Meo
01/14/2014 04:01 PM
Release Readiness : From SNAPSHOT to Release &
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
release) is to move from SNAPSHOT
versions of the bundle to the release version. This release
the bundles are deemed the stable version.
As per the collective decision during the TSC call, we decided
the process of cutting over from SNAPSHOT
to the release version on 01/27 & we expect this process to
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
This email will provide the recommendation for cutting-over to
versions and the subsequent branching strategy.
This is a heavy topic and we have a ton of information to share
Short list of Things TODO for Project Owners and Project
start working on today (01/14/2014)
0. Finish up the "Release Readiness : Dependency convergence"
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
the exact <scm> section.
1b. Add maven-release-plugin to the plugin management
section of your project (refer to
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
3. We will be using maven-release-plugin. Hence please review :
4. Thank god, we have Giovanni amongst us :-), he already went
the painful process of releasing artifacts from the controller
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
dependencies was identified on controller depending directly on
We have to remove this dependency from the controller
6. It is recommended to start with the 1.0.0 as the
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
to do this as a group with representatives from all the projects
1. Based on the dependency tree evaluation, we have to perform
process in the following sequence
- openflowjava , ovsdb, opendove, vtn, affinity, bgpcep,
lispflowmapping, snmp4sdn, defense4all (all these projects can
- 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
the changes to your repo.
3. In each project, we have to copy both the Prepare-only &
jenkins jobs from the controller project & adjust it to
4. Execute the prepare-only jenkins job and make sure all the
resolved and we get to a successful execution.
5. Execute the Final-publish job (bulk-release) on your project
publish the artifact to the nexus repo.
6. In Step4, the maven-release-plugin would also drop a tag in
repo to mark the exact release point. We can either manually
create a branch
each of the project with a Branch version (please note
that this Branch version is Nothing to do with the artifact
they are different in each bundle)
or automate the branch creation on the jenkins job.
Ofcourse, there are tons of detailed information available on
Please dont take this lightly. Tons of stuffs to do in getting
the release out & hence your attention to this is highly
controller-dev mailing list