I'll also note that 'git pull --tags' will update any tags that have changed, despite what the man page for git-tags actually says.
B. On 21 October 2011 17:39, Robert Dionne <[email protected]> wrote: > > > On Oct 21, 2011, at 12:33 PM, Paul Davis wrote: > >> 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. > > I think this is pretty common > > > >
