couchdb-dev mailing list archives

On Oct 21, 2011, at 21:26 , 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,
I really like the idea of immutable tags, now that we can have them and the final move from
x.y.z-rcX to x.y.z for the passed release including keeping tags for votes that were turned
down.
I'm also totally happy to call it x.y.z-vote1, -vote2 etc. to avoid confusion with RC releases
that are releases as defined by the Apache release procedure that I know other projects do.
Cheers
Jan
--
>
> 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.
>>>>
>>>
>