I like it, +1. I'll note that the copied tag '1.1.1' from '1.1.1rc1' will look a little strange. It will be exactly the same as the '1.1.1rc1' tag, including *saying* 'tag 1.1.1rc1' in the tag body (when you view it with git tag -v 1.1.1, for example). I'm fine with that, it's pointing at the same stuff and it's a record of the fact that rc1 was blessed as the actual release, but I mention it because it's odd.
B. On 19 October 2011 17:55, Paul Davis <[email protected]> wrote: > Devs, > > Now that we're on Git and have a system for managing tags that isn't > nutty, its time that we should revisit our tagging protocol for > releases. > > First, a note about the Git hosting. One of the ASF requests was that > I write a thing that prevented the ability of rewriting history on > master. When I implemented this I made the branch pattern configurable > to multiple branches. Currently this protection applies to master, > trunk, and any branch or tag prefixed with "rel/". The idea was that > we'd be able to move release branches like 1.1.x, 1.2.x etc to > rel/1.1.x and rel/1.2.x so that we don't accidentally break them. The > same for tags. Once we tag something as rel/1.1.1 the rewrite checks > will prevent someone from accidentally modifying it. > > So given that, and the fact that Git lets us alias specific tags > exactly, I thought I'd propose a couple slight tweaks to the release > procedure. > > 1. When tagging release candidates, the tag would be of the pattern: > > tags/rc/X.Y.Z-rcN > > 2. When a release formally passes a vote, we would copy the tag to: > > tags/rel/X.Y.Z > > 3. I think we discussed this before, but we should also place the rc > artefacts into a directory named as such (IIRC, we decided that the > name shouldn't change). Ie, 1.1.1 would be stored at: > http://people.apache.org/~rnewson/dist/1.1.1/rc1/apache-couchdb-1.1.1.tar.gz > > 4. Making new release branches we should name them: > > branches/rel/X.Y.x > > 5. For continuity, I'd also propose copying all of our older tags and > branches to the new pattern (while keeping the current versions around > for an extended period of time). > > Thoughts? >
