couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: Tweaking the release procedure
Date Sat, 22 Oct 2011 08:53:53 GMT
To Jason:

"That sounds like a tag by another name."

Yes, exactly. The point is that the thing I'm attempting a release
from already has a universally agreed and unambiguous name already, so
let's use it.

To Everyone:

I'd argue that it is of no interest, after a release, what the release
artifacts looked like in earlier, failed rounds. We can decide, as a
community, that there's value in that but I don't see it. If we go
with reporting the commit id, then you can find them from the mailing
list archives if you want.

This thread has ranged far and wide but I still think the 'only tag
the release at the end' policy is clear, simple and preferable to the
alternatives proposed so far.

As for the fact that 1.2 does not descend from 1.1, this is more than
just a limitation of svn (where a commit can have only one parent).
1.1.x and 1.2.x (and releases from either) necessarily diverge and so
our source repo should reflect that.

Is there a complete alternate proposal to the 'only tag the release at
the end'? Do we feel we're close to finding one?

Finally, it seemed obvious to me that the tag would be signed by the
same key that the release manager signs the release artifacts with, so
I was already doing that. I like the idea that the tag should contain
the tally of votes (including the links to the mail archive). I'll do
that for 1.1.1 if no one objects.


On 22 October 2011 06:19, Dustin Sallings <> wrote:
> On Oct 21, 2011, at 9:08 PM, Noah Slater wrote:
>> Because 1.1 might have features in it that 1.2 does not. Or 1.1 might have a
>> security problem that 1.2 does not.  As Adam points out, there are many small
>> changes to files such as CHANGES or that are never
>> forward-ported. This kind of things goes on more than you might imagine. 1.1
>> is a branch of trunk, and it very likely has things in it that no future
>> branch will ever have. The lineage of CouchDB is not a big long line, one
>> release following on from another. It is much better to think of it as a
>> tree, with branches coming off from it.
>        I've never considered CHANGES, version numbers, or any other such thing that's
managed by the revision control system as part of the source code, so I don't suffer these
limitations in my projects.
>        I write my human readable changelog directly into my tag and also generate
a commit log to go along with the release.  So, so many maintenance issues have gone away
in every project I've done that in.
>        Consider my java memcached client.  The tag itself defines the tree version.
 There is exactly *one* place where the number is defined.  The build system picks up that
number and uses it to number itself.  While it's in there, it grabs the whole change log
and makes it available via a command line:
>        The first file there is showing the output of introspection commands on the
.jar itself.  The second is showing the tag the human typed up for release.  The source
doesn't change when we branch.
>        memcached has similar things for autoconf.  The version number exists in
only one place, so merging conflicts have nothing to do with administrative stuff.
>> Again, this assumes a linear progression of changes, which in reality does
>> not exist.
>        The only assumption I'm making is that you're not concurrently innovating
on 1.1.x and 1.2.x and planning to maintain both forever.
>> I am not sure I understand this point. Are you suggesting that in order to
>> enforce an artificial linear progression of changes we should do fake noop
>> merges of any changesets applied to older release branches on to newer
>> release branches, even if those changes make no sense (such as updating a
>> line in or apply to non-existent bits of code? I'm sorry, but
>> I m
>        Nope.  I'm suggesting that the set of changes contained within the "maintenance"
branches and the "new" branches (as well as other "maintenance" branches) will continue to
grow and you'll have to have tools or procedures to know what changes went into one place
that didn't go into another.  I'd prefer to just say, "What's in 1.1 that's not in 1.2?"
(a trivial commandline op) and have it tell me "nothing" most of the time.  A growing list
that requires people to think about stuff makes it easier to make mistakes.
>        This strategy predates my git experience, but git only makes it easier.
>        I'm not talking about something particularly strange enough to be labeled
"fake", but pulling it up from more to less firm trees means always knowing the state of things.
 Things that don't apply have to be resolved.  A perfectly valid resolution is "just keep
what I have".  The histories merge so you can note in the merge that the bug was in code
that no longer exists, but you've *explicitly* done that in a machine trackable way.
>        We actually have the same kind of thing going on in memcached right now.  There
are a lot of bugs fixed in the 1.4.x branch that don't exist (or are applied considerably
differently) in 1.6.x.  Either way, I will record the 1.4 changes in the 1.6 history.
>> Again, this assumes a linear progression of changes. Like I said above, it's
>> more like a literal tree trunk, or perhaps a set of parallel universes.
>> Every time we cut a release branch, we're creating an alternate reality for
>> CouchDB. Most of these wither away. For a short time, we will back-port
>> fixes for them, or even apply fixes to them that never get forward ported.
>> But they are separate time-lines, and they need to be thought about and
>> managed as if that were the case. It's tricky at times, sure. But there are
>> tricker parts of the release process!
>        It's a graph.  Just because I can draw a line between two points on the graph
doesn't mean that I think it's linear.  It really doesn't matter whether it's linear or if
every couchdb contributor wrote a non-conflicting change at the same time and you did a 256-way
octopus merge -- or anything in between.
>        At the end of the night, a single commit represents the head of a branch or
the commit pointed to by the tag.  A merge-base exists between that and any other branch
in your system and you have tools that can tell you all the things that are to the left or
the right of that merge-base (or more if you're looking to do an n-way octopus merge across
more than two -- I've done up to 24 myself).
>        I can do uni- or bi-directional set differences or just straight up diffs
from either point and think about what the results mean.  In practice, I can't justify excluding
changes from our 1.4 releases when we prep the 1.6 release.  It just gives me too much to
think about (there are 444 new changes in one direction and 16 in the other).
> --
> dustin sallings

View raw message