couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: Tweaking the release procedure
Date Fri, 21 Oct 2011 18:29:02 GMT
>From the other thread, reposted here on Noah's suggestion;

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 19:25, Robert Newson <robert.newson@gmail.com> wrote:
> Dustin,
>
>
> /tmp/bar $ git --version
> git version 1.7.6.1
>
> /tmp/bar $ git pull --tags
> remote: Counting objects: 4, done.
> remote: Compressing objects: 100% (2/2), done.
> remote: Total 3 (delta 0), reused 0 (delta 0)
> Unpacking objects: 100% (3/3), done.
> From /tmp/foo
>  - [tag update]      1.0        -> 1.0
> Fetching tags only, you probably meant:
>  git fetch --tags
>
> The 1.0 tag was correctly updated.
>
> B.
>
> On 21 October 2011 19:11, Noah Slater <nslater@tumbolia.org> wrote:
>> On Fri, Oct 21, 2011 at 7:04 PM, Dustin Sallings <dustin@spy.net> wrote:
>>
>> IMO, simplicity and conventions win here.  Tags should be treated as
>>> immutable pointers to commits that had some meaning and should be named and
>>> labeled meaningfully as well.  Branches are pointers to works in progress.
>>>  When work is "finished", they can be tagged and deleted.  If you do this,
>>> all of the defaults work and you don't have to invent and document as much.
>>>
>>
>> The only way I can see this working then is to "move" the tag once a vote
>> passes. Whether this involves duplicating the tag, or creating a new one
>> that points to the same thing, I don't know. Other people with more Git-fu
>> can step in here. But we need a way of blessing tags that works with
>> downstream repositories, and that separates them out from defunct tags that
>> never made the cut.
>>
>

Mime
View raw message