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:34:45 GMT
Sorry for the self-reply, but I read the thread of Bob's comment and I see that he dismissed
my concern as irrelevant.  Well, fine then :)  If you want to solve this by fiat and say that
users are not allowed to rely on their local copies of our signed tags as authoritative then
these debates are a waste of time.  Best,

Adam

On Oct 21, 2011, at 3:26 PM, Adam Kocoloski wrote:

> 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