If other projects jumped off a cliff, would couch? I, for one, say no. B.
On 21 October 2011 17:33, Paul Davis <paul.joseph.da...@gmail.com> wrote: > On Fri, Oct 21, 2011 at 4:28 AM, Jukka Zitting <jukka.zitt...@gmail.com> > 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 <paul.joseph.da...@gmail.com> >> 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. >
