Paul, +1 to the broad strokes, but I'm a little confused about the specifics. Do you really want branch names to start with "branches/" and tag names to start with "tags/"? Or is that just a bit of abstraction leakage from the git internals?
Branch names like rel/1.1.x for non-rewriteable release branches are fine by me. Tags like rc/1.1.1rc1 and rel/1.1.1 I'm not so excited about. Are you trying to use those prefixes to enforce that the tags are immutable? If so, then I guess it makes sense, though maybe we don't need to repeat ourselves and instead use rc/1.1.1-1. Bob, I think it's a good thing that copying the accepted release candidate to the final release tag preserves the relationship between the two things. I don't find it off-putting at all. Thanks for getting this discussion going guys. Adam On Oct 19, 2011, at 1:11 PM, Robert Newson wrote: > 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? >>
