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

[Hans-Christoph Steiner]

On Jul 19, 2012, at 5:31 AM, Ferry Huberts wrote:

> 
> 
> 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.
> 
> I'd prefer to have this done with a merge, so that there's no surprises when people are pulling.
> 
> You can do this (before renaming branches):
>  git checkout stable
>  git merge --no-ff -s ours
> 
> 
> 
>> 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.
>> 
>> 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 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.


This sounds like a good idea.  I just want to make sure we are talking about the same thing.  I think the olsrd git workflow should match the workflow of the people actually working on it, and this is pretty close.  That's the real power of git.

As far as I see the workflow, we have two types of contributions in the recent past: 

1) a couple people working quite a bit on very specific things (pud, jsoninfo, etc. )
2) a number of people contributing patches to fix bugs

The release once a release is made, no bugs are fixed in that release (i.e. there isn't 0.6.2.1, 0.6.0.1, etc.).  After a release is made there is sometimes is a burst of dev activity, and close to the release, there is a focus on bug fixes only.

So I'll take what was already written and add to it, based on my understanding:

- 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 current 'stable' branch becomes the new 'master'
- master is the main development branch is always open for committing.
- when the release cycle is started, a new branch with the upcoming
  release version is made (i.e. stable_0.6.4).  Only fixes are committed
  or cherry-picked here.
- work on bug fixes should focus on the stable_0.6.4 branch and be
  only committed there.
- 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.
- bug fixes from stable_0.6.4 are folded into master, either merged
  or cherry-picked

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.

.hc