couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@tumbolia.org>
Subject Re: Tweaking the release procedure
Date Fri, 21 Oct 2011 19:49:17 GMT
Can we do something like this:



On Fri, Oct 21, 2011 at 8:42 PM, Dustin Sallings <dustin@spy.net> 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?
>
> --
> dustin sallings
>
>
>
>

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