couchdb-dev mailing list archives

I'm officially kicking of the 1.0.3 release procedure.
Everyone should double check the NEWS and CHANGES files and tell me
that everything is ok on that end. Then you should vote whether to
continue along with things. I'll be making a dry run of rolling the
tarball tonight and tomorrow I'll start off the actual release vote
baring any concerns.
POSSIBLE RELEASE PROCEDURE UPDATE:
During the 1.0.2 release it became apparent that when a vote fails and
we have to redo the whole thing that it can become confusing what's
being voted on as there exists multiple tarballs that have the same
filename. It was suggested during the last round that we adopt an rc1,
rc2... style strategy. This is all fine and good. Tags and release
names can be managed easily enough, but it brings up a question.
How do we go from the final rcN candidate to an actual release?
My first thought was to update acinclude.m4.in so that the names are
all automagical. The downfall of this is that the rcN is contained
*inside* the tarball which affects the signatures. That's significant
because in theory we're supposed to be voting "on the exact tarball
that becomes version x.y.z".
The obvious thing to do otherwise would be to just rename the tarball
and signatures after running make distsign, but that's kind of a lie
because when you build and run the artifact it won't have the correct
version.
Anyway, I don't want this to be a bikeshed before a 1.0.3 release so
if it becomes one I'll veto the idea and pretend I never suggested it.
Humbly yours,
Igor the Release Manager