On Wed, Oct 19, 2011 at 12:28 PM, Adam Kocoloski <kocol...@apache.org> wrote: > 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? >
Sorry, yeah. Before I had those it was a bit confusing between "rel/1.1.1" and "rel/1.1.x" where one is actually an internal name of "refs/tags/rel/1.1.1" and the other is "refs/branches/rel/1.1.x". Just wanted to make that more apparent. > 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. > Well, the rel/ prefix is for the pattern match to enforce the non-rewriting part. The rc/ is just convention and would be rewritable. Or we could just disallow rewriting of any tag and then have "1.1.1-rc1" "1.1.1-rc2" "1.1.1" etc etc. I don't have a huge investment in the rel/ prefix by any means. Was just considering that we have the capability so wondering if people would want to use it. > 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. > +1 > 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 <paul.joseph.da...@gmail.com> 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? >>> > >
