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

Ferry Huberts (spam-protected)
Thu Jul 19 11:20:20 CEST 2012



On 19-07-12 10:30, Henning Rogge wrote:
> Hi,
>
> I think its time to test a new release system for the next release,
> otherwise we will get nowhere with it.
>
> Based on the discussions  we had in the last months I think we need two
> things:
>
> - a place to push new stuff which will be integrated into the next release
> - a place to push bugfixes for an existing release (and bugfixes only!)
>
> My current plan for this is the following.
> 1) I will rename the "master" branch into "historic_master" in the next
> days.
>
> 2) When we start with the 0.6.4 release, I will create a new master
> branch, based on current stable.
> 3) I will also create a "stable_0.6.4" branch where we can put fixes for
> 0.6.4
> 4) We then can test the 0.6.4 branch for build problems. As soon as the
> packet maintainers and testers agree, we will tag a 0.6.4 release.
>

yay!
completely what I'd do too :-)

> New development can be done in the master branch... if someone wants to
> work on something big, he can either create his own branch or use his
> own repository... using your own repo has the disadvantage that you most
> likely will not get much feedback.
>
> We just need to keep an eye on "fixes" in the master and cherry pick
> them for the current "stable".

I propose to have the following convention (taken from the Mesa OpenGL 
project):

- If a patch/commit fixes an existing problem on the stable release,
   then add the following text to the commit message:
     'Note: This is a candidate for stable release branches.'

>
> I plan to remove the stable branch completely, so we do not have the
> problem of people pushing into a "stable branch" because the didn't
> heard about our change.
>
> @Hans Christoph: Do you think we should also create a 0.6.3 branch to
> collect bugfixes for the Debian release version? This would simplify
> maintaining the Debian packet I think.

I would propose that we only do fixes on the released version, not on 
versions before that.
In this case that would mean that we don't need a v0.6.3 branch since we 
obsolete 0.6.3 by releasing 0.6.4



>
> Comments?
>

Excellent proposal

-- 
Ferry Huberts






More information about the Olsr-dev mailing list