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. B. On 22 October 2011 06:19, Dustin Sallings <dus...@spy.net> 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 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 > > > >
