David Jencks wrote:
On Jun 15, 2006, at 10:31 AM, Bill Stoddard wrote:
David Blevins wrote:
Comment from the peanut gallery...
It is extremely poor form to modify 'tagged' releases. Once a
release is tagged in SVN, it should not be changed, ever.
We don't update tags.
That's good.
1.1 should not have been tagged until after the vote to release 1.1
passed. FWIW.
It's been our tradition to insist the releases are built from the tag.
1.1 is tagged. What happens if the 1.1 release vote fails because of a
show stopper bug?
IIRC this happened repeatedly with 1.0. We deleted the tags/1.0 and
made a new one, using, IIRC, svn cp.
As I mentioned in another post, I don't have a big problem with this
since you don't lose any history by doing this, unlike cvs where moving
tags destroys history. It does make the history a bit hard to find
however, and we might consider using "maven build numbers" such as
tags/1.1.1-3 for the third try to release an acceptable 1.1.1. I'd
rather continue as we have been, deleting and recreating tags. I'm open
to argument however :-)
svn solves the history problem, however if your constantly changing the contents of the 1.1 tag (by deleting
and recreating the tag) then how are AG users to know that they have the official AG 1.1 release? Why not
eliminate the opportunity for users to get different versions of what they believe to be the "true" 1.1?
I've seen this problem solved in a couple of ways. Apache HTTP Server takes the view that "version numbers are
cheap". A release is tagged and if it proves buggy, the bug is fixed and a new version number is assigned.
Many tagged versions never make it to "generally available" status. Other projects create tags like 1.1-rc3.
rc3 may very well become the generally available "1.1" release. I am sure there are other ways to solve the
problem.
All that said, I am just sharing my experience from working on other open source projects over the years. Do
what you think is right and have fun ;-)
Bill
