couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: Tweaking the release procedure
Date Sat, 22 Oct 2011 04:08:16 GMT
On Sat, Oct 22, 2011 at 3:25 AM, Dustin Sallings <> wrote:

This makes sense if 1.1.1 was released after 1.2, but why would you not want
> to include the 1.1 changes in 1.2?  As much as I dislike using perforce and
> its like, I find Laura Wingerd's Tofu Scale to be a good generally working
> model.

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.

> For example, let's say 1.1 is stable, released version of software and 1.2
> is a stabilizing, about to be released piece of software.  A bug fix that is
> important enough to require a fix in the previously released version should
> also be required for 1.2.  Ideally, you make the fix in 1.2 (the firmest of
> branches), and then merge it up.

Again, this assumes a linear progression of changes, which in reality does
not exist.

       This is true even if the broken functionality no longer exists,
> because it very clearly marks that the bug doesn't exist and how it came to
> not exist (git makes it easy to do what is effectively a NOOP merge).

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

> The end result is you can easily ask what's missing in either direction
> between any two points and nothing gets lost.  Show branch, github branch
> view, etc... will happily show you when a maintenance branch has crept ahead
> of a development branch.  Otherwise, it's a lot of work to ensure things
> don't get dropped.  I generally prefer to leverage the tools that can do
> this reliably for me.

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!

I'm looking at you, GNU.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message