[Olsr-dev] 0.6.4 release and "howto do it"

[Hans-Christoph Steiner]

On Jul 25, 2012, at 3:33 AM, Henning Rogge wrote:

> On 07/22/2012 04:27 PM, Hans-Christoph Steiner wrote:
>> The Linux kernel workflow is vastly more complex than the olsrd
>> workflow, with layers and layers of people surrounding Linus, each
>> maintaining their own Linux repos.  It also has longer and much more
>> complex release cycles.  For example, Linus puts outs many RC
>> releases for each point release, all while the layers of people
>> around him are also putting out their own RC releases.  So its easy
>> to see how commits could get lost in all that.   olsrd currently
>> doesn't put out any RC releases.
> 
> "The plan" calls for an "RC branch" (which is just the stable branch of a new release before we tag the release), but I hope we don't need RC releases.
> 
> We tried it and it didn't worked out well. We are a small enough group that we can have a "rolling release candidate" and just release when things calm down.
> 
>> I've been happy with the bug-fixes-in-release-branch workflow for a
>> number of years maintaining Pure Data, which is of similar scale to
>> olsrd.  It works well if there is a general agreement to take a brief
>> pause (like a week or two) from normal development and focus on
>> getting out a stable release.
> 
> As long as we merge/cherry-pick them over to master after we did the stable release, that should be fine.
> 
> I was thinking about fixes for already released stable branches. Lets say we find a bug in the latest stable release that needs to be fixed quickly, we can commit it to the "v0.6.4" (or later) branch and then tag a 0.6.4.1 a day later.
> 
> Without having to go through the whole "stabilization phase" of everything new in the master.
> 
>> I suppose it might not work well if there is a lot of asynchronous
>> dev activity, since those devs who are out of sync would not be aware
>> of the release cycle when the synced devs are focusing on release
>> bugfixes.
>> 
>> One thing about keeping the bugfixes in the release branch during the
>> release cycle is that I think it would be easier to rebase the
>> commits in the release branch on master than vice versa.
> 
> I am not sure I understand what you mean here. Rebasing a published branch sounds like a bad idea. Did you mean merging?

If there are two separate branches, 'master' and 'stable-0.6.4', and some bug fixes were committed to stable-0.6.4 while some ongoing development work was happening in master, then it would be cleanest to rebase the bugfix patches on master before committing them.  This would not touch the commit in stable-0.6.4.

Otherwise, you get lots of merge commits, which are mostly noise, IMHO and are best avoided when possible.  Cherry-picking basically sets you up to rebase like this, if I remember correctly.

.hc