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.new...@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 <nsla...@tumbolia.org> wrote: >>>> On Fri, Oct 21, 2011 at 7:04 PM, Dustin Sallings <dus...@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. >>>> >>> >
