[Olsr-dev] 0.6.4 release and "howto do it"
Thu Jul 19 18:36:02 CEST 2012
On Jul 19, 2012, at 5:31 AM, Ferry Huberts wrote:
> On 19-07-12 10:30, Henning Rogge wrote:
>> 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
>> - 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
>> 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
>> 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
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.
More information about the Olsr-dev