couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: Tweaking the release procedure
Date Fri, 21 Oct 2011 22:14:23 GMT
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 <nslater@tumbolia.org> wrote:
> On Fri, Oct 21, 2011 at 10:23 PM, Robert Newson <rnewson@apache.org> 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?
>

Mime
View raw message