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

[Henning Rogge]

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?

Henning

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:(spam-protected) http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6169 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20120725/fa1c17b6/attachment.bin>