On 06/25/2012 12:32 PM, Vincent van Ravesteijn wrote:
Op 25-6-2012 18:27, Richard Heck schreef:
On 06/25/2012 12:10 PM, Vincent van Ravesteijn wrote:
Op 25-6-2012 17:36, Richard Heck schreef:
With git, it no longer seems necessary to close branch to do a
release. I propose in future to do the following, starting with 2.0.5:
1. At release time, create a 2.0.5 branch, where any additional
work that might need to be done can be done.
2. Change configure.ac to 2.0.6dev, so work can continue there
3. When I actually release 2.0.5, create a tag on that branch
The only downside to this is that there will be more branches
hanging around, but this doesn't seem like much of a cost, and it
will make the 2.0.x branch cleaner.
Thoughts?
In what sense does it make it cleaner ?
In the sense that its history is cleaner. The back and forth with
version numbers etc isn't in that branch, or the string remerge
before release, or whatever.
The version numbers only go forth right ? 2.0.5dev -> 2.0.5 ->
2.0.6dev -> 2.0.6 etc.
Yes, of course. But this way it goes 2.0.5dev --> 2.0.6dev, in 2.0.x,
with the other changes off to the side.
The general thought is that there are things one does to the branch for
release that don't really count as work on the development branch.
They're really things you're doing just so you can prepare the release.
It seems like an obvious place for a new branch.
You don't want the string remerge to be in the 2.0.5dev branch ? I
think you must have it there as well ?
I usually remerge again after release, to pick up the changed version
number again. So you end up with an extra commit in that branch.
We could remerge all of that back into 2.0.x, but the only changes
we'd be merging would be ones we had just undone again, unless, of
course, something substantial had to be done, and then of course that
would be merged (or cherry-picked, or whatever).
Which changes do you undo ?
The configure.ac version change.
Richard
