couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Tweaking the release procedure
Date Sun, 23 Oct 2011 01:50:42 GMT
On Sat, Oct 22, 2011 at 1:00 PM, Noah Slater <> wrote:
> Jason and Randall, thanks for your dive into the semantic versioning idea.
> As you pointed out, CouchDB's use of (as I mentioned previous) the Apple
> versioning scheme means that it is indistinguishable from the semantic
> versioning concept. However, I don't buy that we need to be shoehorning
> "rc1" or "vote1" into the version number so that we can tag it without
> conflicting with our actual releases.
> Dustin, thanks for your illuminating response. Some of the things you
> describe there sound quite interesting, especially the build related
> automation of release details such as version numbers and changelogs. I
> guess there might be room for innovation, but that's something I'd like to
> look at another time. The Git stuff sounds cool too, though a little beyond
> me at this point I will admit. There might be room for improvement in how we
> manage our release branches. Perhaps other people, like Paul, want to weigh
> in on that?

Honestly, I stopped caring about 50 emails ago. Next time I cut a
release I'll read the CliffsNotes.

> My most pressing concern at the moment is that whatever we decide in this
> thread should apply to the whole gamut of Apache projects, in broad strokes.
> We're actually quite unusual in the fact that we use the GNU Autotools. Most
> of the other projects use some crazy Java stuff I don't even understand. But
> we can't attempt anything to fancy here, or anything too specific to our
> particular set up.
> On Sat, Oct 22, 2011 at 9:53 AM, Robert Newson <> wrote:
>> 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.
> I agree.
>> 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.
> It sounds like Dustin has some interesting ideas on how to manage our
> back-porting and forward-porting procedures. Managing release branches has
> been quite tricky in the past. And if someone with lots of Git-fu wants to
> help us manage that process better, I am excited about that. I don't think
> this is particularly important for the current discussion though, so is it
> best to come back to this later?
>> Is there a complete alternate proposal to the 'only tag the release at
>> the end'? Do we feel we're close to finding one?
> I don't think so, and I doubt it.
>> 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.
> +1 to the tag being signed by the same GPG key as the release artefacts.
> The mailing list already contains the history of the votes, and the tally of
> the final round. It should only be necessary to include a reference to the
> final vote tally. The rest can be done by whomever it is following the link.
> I don't think it's necessary to include the release announcement or anything
> else like that in the tag. Besides, it's important to realise that at the
> point the tag is cut, this email hasn't even been sent yet.
> I would suggest something along the following lines:
> -
> Apache CouchDB 1.1.0 was tagged following a successful vote:

View raw message