couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: Tweaking the release procedure
Date Thu, 20 Oct 2011 01:56:06 GMT
On Oct 19, 2011, at 9:04 PM, Dustin Sallings wrote:

> On Oct 19, 2011, at 2:33 PM, Noah Slater wrote:
>> Why not just have a top level tags/ directory that prevents rewriting. In
>> that you'd tag a release candidate as X.Y.Z-rc1, X.Y.Z-rc2, etc until a vote
>> passed, at which point, you copy the tag to X.Y.Z. I don't see a need
>> to separate these out with a second level directory.
> 	Probably best to not consider tags as svn refers to them.  It's not a copy, just a pointer
to a commit that was the last one in the release (which, in turn, points to the commits that
preceded it).
> 	In git, tags generally get a ref prefix of refs/tags/ (it's more of a namespace than
a directory).  I'd recommend not doing anything different from what git will give you out
of the box.  Tag your rc, tag it again when it becomes a release.
> 	Tags are intentionally hard to rid yourself of in git.  Once you publish a "this is
2.5", getting a second chance requires coordination.  You can overwrite them locally, of course,
but once they're published and replicated, the down streams basically have to agrees to move.
> 	I'm a bit of a bystander, but I'd really want to see strong justification for not wanting
to use git's normal tools and methodologies.
> -- 
> dustin sallings

I think you might be reading a bit too much into what Noah is saying here.  I believe he's
just taking issue with the two separate rc/ and rel/ "paths" in the tag names.  For what it's
worth I agree with him on that front, though I'd consider going even further (as Paul suggested
earlier in the thread) and just prevent rewriting of any tag pushed to the ASF remote.  Then
there's no need for any tag prefix at all.  Best,


View raw message