The only annoying factor is that I can no longer delete the 1.1.1 tag (I have deleted it before);
~/source/couchdb $ git push origin :refs/tags/1.1.1 remote: env: python: No such file or directory So, unless someone else can delete it, it will hang around until I change it to its final value. I *won't* be changing it for round 3 or higher, though, as per the above proposal. I'd like a few more +1's for the 'use commit id until official release' policy but there's time, since we're waiting on a Windows fix for the basename() issue. To clarify how the vote emails would look, the previous email said; These artifacts have been built from the 1.1.1 tag in Git: and, under the new policy, would have said; These artifacts have been built from commit 89f7faa6d09248999fb51ffd2a13777168f51805 B. On 21 October 2011 23:06, Noah Slater <[email protected]> wrote: > On Fri, Oct 21, 2011 at 10:23 PM, Robert Newson <[email protected]> wrote: > >> Here's another suggestion. >> >> In all vote emails, we include the commit id that the release >> artifacts were built from, but create no tag at all. >> >> When the release passes the votes, we create the tag, with its final >> name, against that commit id, and push it at the same time we upload >> the artifact to the mirrors. >> >> To obviate any concern about stale 1.1.1 tags in downstream repos, we >> could, for this release only, add a 1.1.1-final tag as an unambiguous >> tag, but only *after* the release is official. >> >> Stated another way; we make each tag exactly once, and refer to the >> build by its commit id until then. Since a commit id in git dictates >> the precise state of the entire tree this is safe. > > > I love it when something is so obvious you wonder why it wasn't apparent in > the first place. I love this suggestion, and the specifics of how you > communicate the git commit hash is unimportant. If there's a "describe" > command to make it easier, so be it. We only tag when we mean to tag a > release, for reals. > > As for the existing Git tags, I don't want to mess things up with a > 1.1.1-final tag. Let's just accept the fact that some downstream > repositories may have stale 1.1.1 tags from the previous two rounds, and go > ahead and delete them. Once the vote passes on 1.1.1, we create a "1.1.1" > tag as per this suggestion and request that people update their downstream > git repos to make up for the fact we've now solidified our release procedure > in a way that means those old tags need to be deleted. Make sense? >
