couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@tumbolia.org>
Subject Re: Tweaking the release procedure
Date Sat, 22 Oct 2011 18:00:27 GMT
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?

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 <rnewson@apache.org> 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:

http://mail-archives.apache.org/mod_mbox/couchdb-dev/201106.mbox/%3CBANLkTinLheqbrD_=zV0i1ShLEyaD8-L=4Q@mail.gmail.com%3E

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