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

[Ferry Huberts]

On 19-07-12 20:57, Hans-Christoph Steiner wrote:
>
>
> 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.
>

PS. I'm missing the pud plugin in the Debian package. Perhaps that can 
be added soon? (you know, to motivate me to fix issues...)


-- 
Ferry Huberts