>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. >> >
