[Olsr-dev] 0.6.4 release and "howto do it"
Wed Jul 25 09:33:58 CEST 2012
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
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
> 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?
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961, Fax +49 228 9435 685
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6169 bytes
Desc: S/MIME Cryptographic Signature
More information about the Olsr-dev