couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Tweaking the release procedure
Date Fri, 21 Oct 2011 20:09:07 GMT
On Fri, Oct 21, 2011 at 2:42 PM, Dustin Sallings <> wrote:
> On Oct 21, 2011, at 11:25 AM, Robert Newson wrote:
>> /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.
>        You aren't disagreeing with the thing I'm most concerned, but the thing I'm
second-to-most concerned about but directly brought up.
>        I pointed out that you can't *remove* tags, since that's what's required for
a renaming strategy.  Here you're just showing that if every user everywhere who has a clone
of the official repo issues a non-default update command before looking at tags, then there's
no problem.  I think this might be less reasonable than it sounds.

I think our wires were crossed a bit. The rename isn't really a rename
directly. Once a release is made, we just copy the final vote tag to a
new tag that is prefixed/suffixed/something to indicate "this is the
tag that corresponds to what's in the dist directory."

Removing tags would occur after a final vote passed and would only be
a minor "maybe get rid of cruft to avoid confusion" step.

>        For example:  Let's say I'm doing an automated build for my OS distribution
from the 1.0 tag and have shipped stuff out to my customers.  How will you know that there
was no failure in my two tiers of git repos that caused my build to miss the update to your
1.0 tag between the time that you issued the first one, announced the second one, I did an
update from a mirror during an upstream outage and see the 1.0 tag and ship it and then find
a bug?  Which 1.0 did I ship?

Right, this is the current state of affairs we've been dealing with
using SVN and what we're looking to fix.

> --
> dustin sallings

View raw message