couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dustin Sallings <dus...@spy.net>
Subject Re: Tweaking the release procedure
Date Sat, 22 Oct 2011 05:19:34 GMT

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 acinclude.in 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:

	https://gist.github.com/gists/1305645

	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 acinclude.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




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