couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <kocol...@apache.org>
Subject Re: Tweaking the release procedure
Date Fri, 21 Oct 2011 19:26:28 GMT
Hmmm ... that's all well and good, but I envision more confusion ensuing in the case where
we have multiple possible values for '1.1.1' floating around the internet than I do in the
case where we have '1.1.1-rc1', '1.1.1-rc2', and eventually one single immutable '1.1.1'.
 Best,

Adam

On Oct 21, 2011, at 2:29 PM, Robert Newson wrote:

> 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