On Fri, Oct 21, 2011 at 4:28 AM, Jukka Zitting <[email protected]> wrote: > Hi, > > My 2c from the gallery. I'm not involved in CouchDB, so just making > general observations from the perspective of other Apache projects > interested in using Git. > > On Fri, Oct 21, 2011 at 5:51 AM, Paul Davis <[email protected]> > wrote: >> As Noah points out, there are ASF procedural issues that affect this >> discussion. Part of making a release involves getting community input >> on whether the release is a valid artefact. As such we need to be able >> to refer to these "not-release" sets of bytes. > > I'd say that's a perfectly valid use of tags. An official release > should be backed by a tag, but there's no requirement for the reverse. > Using tags for release candidates or other milestones should also be > fine. It should be up to each project to decide how they want to name > and manage tags. > > I also find the idea of renaming a release tag after the vote > completes a bit troublesome. The way I see it, a release manager will > tag a given state of the source tree and use that tag to build the > release candidate. After that no repository changes should be required > regardless of the result of the release vote. If the vote passes, the > candidate packages are pushed to www.apache.org/dist as-is. Otherwise > the release candidate is just dropped and the next one made. > > This kind of a workflow also solves the "1.1.1 vs. 1.1.1-rc1" problem. > If each release candidate is given a separate new tag and version > number (i.e. "1.1.1 vs 1.1.2"), then there can be no confusion about > which build is being tested. Version numbers are cheap. > > BR, > > Jukka Zitting >
Are there projects that do this version incrementing when a vote fails? That's an idea I haven't heard before.
