[Olsr-dev] 0.6.4 release and "howto do it"
Thu Jul 19 22:39:41 CEST 2012
On 07/19/2012 03:33 PM, Ferry Huberts wrote:
> 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.
>>>> - 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
>>>> or cherry-picked here.
>>>> - 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...)
pud will be difficult to include because Debian requires that you use
any libraries in their packaged form rather. Debian includes libnmea,
so to be included in Debian, pud would have to use the Debian libnmea
and ignore the source included with olsrd.
More information about the Olsr-dev