couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: [VOTE] Apache CouchDB 1.1.1 Release, Round 2
Date Fri, 21 Oct 2011 18:13:25 GMT
Yes, quite reasonable.

My take on tagging was to follow what we did with SVN with only minor
changes to account for git. So I shall describe it.

First, I create a signed tag for the release, with its intended final
release value. In this case, exactly the string '1.1.1'. Then I build
artifacts from the tag (which could be from a 'git archive 1.1.1' or
'git checkout 1.1.1 && git clean -xdfq'). When I'm happy with the
output of that phase (i.e, I've done the diff -r, make check, Futon,
etc from the generated tar.gz) I upload it to people.apache.org and
push the tag (so that others can verify that it matches the release
artifact).

In the event of a round veto, I delete the 1.1.1 tag. In the next
round, I create and push a new signed 1.1.1 tag as part of the same
procedure.

'git pull --tags' correctly updates anyone's existing (but now wrong)
1.1.1 tag (the man page for git-tag goes on at some length that it
doesn't do that and how evil such a thing would be, but it does it
anyway).

The arguments in the other thread about immutable tags are laudable
but irrelevant. The tags in our source control system are not the
source of truth for our releases. The presence of the release on the
Apache mirrors is. The entire discussion around -rcX suffixes is to
avoid any confusion between the failed artifacts and the release
artifact. While a genuine concern, it's not worth all this soul
searching in my opinion. The real 1.1.1 comes from the mirrors. When
it's available on our mirrors then it also means that the 1.1.1 tag in
source control points to it (and always will).

B.

On 21 October 2011 18:56, Noah Slater <nslater@tumbolia.org> wrote:
> On Fri, Oct 21, 2011 at 6:23 PM, Robert Newson <rnewson@apache.org> wrote:
>
>
>> nslater: Can we decide now if we're sticking with (approximately) the
>> release procedure we've been following so far or whether we have to
>> nail down all the git things and document before round 3 can begin?
>>
>
> The actual text of the release procedure wiki page is unimportant. I realise
> we want to get this out ASAP, and I don't want to be a PITA. But we DO need
> to nail down how we're tagging releases. As long as we get that far, and as
> along as round three is tagged according to that policy, and as long as we
> write it down afterwards, I think I will be a happy bunny. Am I being
> reasonable?
>

Mime
View raw message