Re: [OpenDaylight Discuss] Hydrogen Stable Release Proposal

Luis Gomez

Hi Ed,

I do not have objection on this way to build the stable branch however we need to clarify what will be the final stable version: <hydrogen-release>-1-SNAPSHOT as originally proposed or <current-version>-1-SNAPSHOT as you are proposing here.


On May 5, 2014, at 11:14 AM, Ed Warnicke (eaw) <eaw@...> wrote:

Chris did a wonderful job for us of collecting good practices for doing stable releases here:
It included committing bug fixes to master first and then cherry picking down the ones appropriate
to a stable release. This is all motherhood and apple pie if you start from your release this way.
Sadly, we did not. We started talking about this several months after our release, and
after tremendous effort (hundreds of patches) had gone into furious bug fixing on stable branches
of our projects.
Trying to replay the sequences of patches, across all of our (12 I believe) projects with various
interdependencies between them has proven to be a herculean task, particularly in light of global
timezones and Jenkins verifies/merges. Lots of projects are getting wedged on other projects
as they attempt to cherry pick down historical patches to a relatively new stable branch.
It appears to me that the root issue is attempting to replay the past.
To resolve this I would suggest that we adopt the following tact:

1) Projects (if they so desire) pull their stable branches from a current point in time (today,or
if it takes us a while to discuss this a little later this week).
2) Projects update their versions to append the -1-SNAPSHOT (we’ve done this already in our first attempt
at this).
3) Projects revert the patches inappropriate for a stable branch (I think most projects have done the triage on this,
so its just a bit of doing, and since most projects have put almost all of their effort on master into bug fixing, is a much
smaller number of things).
4) Going forward we follow Chris’s recommendation to commit *new* bug fixes first to master and then (if appropriate)
to stable (such double committing should be done contemporaneously so we don’t fall back into needing to replay the past).

This should allow us to get unwedged on the ongoing ‘replay the past’ problem and get down to testing and hardening
the stable release.



Discuss mailing list

Join to automatically receive all group messages.