Aaron Mulder wrote:
On 6/15/06, David Blevins <[EMAIL PROTECTED]> wrote:
Exactly that, to make sure people don't "move on" and checkin work on
branches/1.1 for 1.1.1 where there is a freeze on branches/1.1 for
preparing v1.1 (which may not pass it's vote and have to be redone).
OK, so let's say our state today is branches/1.1 and we're about to
cut 1.1.0.
branches/1.1
In order to prepare the release, you copy branches/1.1 to tags/1.1.0
and then (if I understand you right) move branches/1.1 to
branches/1.1.1:
branches/1.1.1
tags/1.1.0
Now you discover that the tag was bad, but code has been checked in to
branches/1.1.1. What do you do?
I don't think this has any advantage over leaving branches/1.1 and
copying it to tags/1.1.0:
branches/1.1
tags/1.1.0
Either way, if the build is bad, you'll have to copy tags/1.1 to
somewhere else to work on it (branches/1.1.0??) until you're ready to
cut another build.
It might be better to just suck it up and cut branches/1.1.0 at the
time of the freeze, and then tags/1.1.0 from that when you want to
create a candidate:
branches/1.1 (now 1.1.1-SNAPSHOT)
branches/1.1.0 (frozen, copied from branches/1.1 at freeze time, only
super-critical changes)
tags/1.1.0 (candidate release, copy from branches/1.1.0)
Then if the tag is bad, whack it, fix up branches/1.1.0, and recopy
tags/1.1.0
I want to point out that this is quite odd, keeping a 1.1.0 branches for
patches for a release that hasn't been released yet. I haven't caught
up with the release versioning discussions yet.
Regards,
Alan
