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 <[email protected]> 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 <[email protected]> wrote: >>> On Fri, Oct 21, 2011 at 7:04 PM, Dustin Sallings <[email protected]> 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. >>> >>
