couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dustin Sallings <>
Subject Re: Tweaking the release procedure
Date Fri, 21 Oct 2011 19:42:25 GMT

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?

dustin sallings

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message