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 Sat, 22 Oct 2011 00:43:40 GMT
On Oct 21, 2011, at 8:25 PM, Dustin Sallings wrote:

> On Oct 21, 2011, at 4:52 PM, Adam Kocoloski wrote:
>> `git describe` would read something like 1.1.0-N-deadbeef, where N is the number
of commits since the last tag.  On .0 releases it would probably just be the commit hash since
the commit would not be a descendant of any tags.  It's a neat tool but I think it might confuse
more than illuminate.
> 	It would be terribly unfortunate if there was no trackable lineage between releases.
 If version 1.2 does not contain version 1.1, then what does it contain?

Hi Dustin, unfortunate or not that's the way it works.  Think about the procedure we've been
discussing in this thread.  All the tags will point to commits on release branches, and those
release branches always contain commits which do not live on trunk/master.  Often trivial
stuff like setting version numbers in autoconf macros, but sometimes not so trivial stuff,
like when we branched 1.2.x so we could get on with the business of landing cool new shit
in master while the code slated for the 1.2.0 release undergoes additional testing and stabilization.

Also, I lied.  In the current repo 1.1.1 does not even descend from 1.1.0.  This is because
the repo is a former mirror of SVN and in the SVN days each "tag" was actually a new branch
unto itself.  The mirror reflects (boo) that fact.

View raw message