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

[Hans-Christoph Steiner]

On 07/19/2012 02:32 PM, Henning Rogge wrote:
> On Thu, Jul 19, 2012 at 6:36 PM, Hans-Christoph Steiner
> <(spam-protected)> wrote:
>> - move current 'master' to some descriptive name, 'historic_master' is ok,
>>   but doesn't say much about the content of what's in that branch.
> 
> The other option would be to put it into a "historic" repository...
> maybe with all other branches that are not in use anymore.
> 
>> - the current 'stable' branch becomes the new 'master'
>> - master is the main development branch is always open for committing.
> 
> Yes
> 
>> - when the release cycle is started, a new branch with the upcoming
> 
> Yes.
> 
>>   release version is made (i.e. stable_0.6.4).  Only fixes are committed
>>   or cherry-picked here.
> 
> Yes.
> 
>> - work on bug fixes should focus on the stable_0.6.4 branch and be
>>   only committed there.
> 
> I would say bugfixes need to be made both in master and stable. Sounds
> stupid not to put the fixes into both branches at once.

I highly recommend it.  It is a good motivator to keeping the release
cycle short.  olsrd is not a large code base, and there aren't that many
contributors.  If the bug fixes are always in both branches, then it'll
drag out the release cycle.  Having the bug fixes only in the release
branch is less work, and is no problem if everyone is focusing on the
getting the release done.

>> - when the release is made, the HEAD of the release branch is tagged
>>   (i.e. v0.6.4) and that branch is no longer used.
> 
> we don't need to create a "release branch", we can just tag a version
> of stable_x.y.z and continue fixing there.

'stable_0.6.4' must be a branch if we want to commit separately to
'stable_0.6.4' and 'master'.


>> - bug fixes from stable_0.6.4 are folded into master, either merged
>>   or cherry-picked
> 
> I would like to do this earlier. Might even be a good idea to fix
> problems in master first (to test them there) and if they work out, we
> can port/cherry-pick them to stable.

>> About the debian branch, I don't think that'll be very helpful.  Its easiest work out of one source repo for that, and that's currently the debian one.
> 
> I would suggest keeping both repositories in sync. But this should be
> easy by pulling the changes from one of this repositories into the
> other one.

The Debian svn repo works with olsrd release tarballs.  The olsrd git
and olsrd Debian packaging are entirely different things.

.hc