[Olsr-dev] 0.6.4 release and "howto do it"
Thu Jul 19 20:32:21 CEST 2012
On Thu, Jul 19, 2012 at 6:36 PM, Hans-Christoph Steiner
> - 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 committed
> 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.
> - 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.
> - 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
Steven Hawkings about cosmic inflation: "An increase of billions of
billions of percent in a tiny fraction of a second. Of course, that
was before the present government."
More information about the Olsr-dev