David Jencks wrote:
On Jun 15, 2006, at 9:58 AM, Donald Woods wrote:
I have to say, that Aaron's view of SVN usage (keeping branches/1.1
around for all 1.1.x releases) makes a lot more sense to me than
forcing people to switch to new branch names...
We should have made a branches/1.1.0 copy from 1.1 , which could then
be moved to Tags once the voting is done. If a major bug needed
fixing due to a -1, then you fix it in branches/1.1.0 and
branches/1.1, respin the 1.1.0 build, revote and then move it to
Tags. That would let people continue working on branches/1.1 with
known items that should go into 1.1.1 and gives you a way to fix any
last minute 1.1.0 release bugs if needed....
Here are my opinions:
-1 on ever removing a branch that we have reasonable expectations of
doing bug fixes on, such as 1.1.
My impression is that we have all agreed repeatedly over and over that
branches such as 1.1 can get bug fixes but NO NEW FEATURES.
Therefore,
+1 to COPYING branches/1.1 to tags/1.1.x for each 1.1.x release, then
building the 1.1.x stuff from that tag.
-0.5 to copying branches/1.1 to branches/1.1.x and then copying or
moving to tags/1.1.x Since ONLY BUG FIXES can possibly be added to
branches/1.1, this should not cause problems. The release manager
gets say over what goes into a release, they can revert changes they
don't want in the release. I think the copy to branches/1.1.x just
adds steps for no gain.
I would upgrade this to a -1 on my part.
Unlike moving tags in cvs, deleting and recreating tags in svn does
not lose any history. Therefore I'm not very worried by Bill's
concern about "changing" tags: my concern is that no one updates the
contents, but deleting a tag and recreating it later isn't a problem
to my sense of history :-). However if we decide that deleting tags
is not such a great idea perhaps we could use build numbers
tags/1.1.1-3 for the third attempt to come up with a 1.1.1 release.
I feel the same way here.
We don't need to have tags/1.1.1-3 since the history can always be
recovered.
Regards,
Alan
