couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <kocol...@apache.org>
Subject Re: Tweaking the release procedure
Date Fri, 21 Oct 2011 19:51:19 GMT
On Oct 21, 2011, at 3: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.
> 
> 	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?

+1

We can argue that the only true '1.1.1' is the tarball you grab from the ASF mirrors, but
realistically the type of scenario Dustin describes is pretty darn common.
Mime
View raw message