Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101189
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.216 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAESVnVq4TQ02RYSWFiBMK132TVX4z8Xyk+QtwbWok7gpfJyg=A@mail.gmail.com>
References: <CANUQDCgePs2B3JrYhWGA3rMW9OM0tmnRpdinPs8=Zkt_vHYDUA@mail.gmail.com>
 <CAESVnVq4TQ02RYSWFiBMK132TVX4z8Xyk+QtwbWok7gpfJyg=A@mail.gmail.com>
Date: Tue, 28 Nov 2017 18:30:30 +0100
Message-ID: <CANUQDCg4KY6vbAkX2URxWdV_V7yUVF=0QwnYCS0VaS=aZ4wWwQ@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: PHP Internals <internals@lists.php.net>, Joe Watkins <pthreads@pthreads.org>, 
	Remi Collet <remi@php.net>, Anatol Belski <ab@php.net>
Content-Type: multipart/alternative; boundary="001a114e59c827eaac055f0e6064"
Subject: Re: Public Tags of Releases
From: me@kelunik.com (Niklas Keller)

--001a114e59c827eaac055f0e6064
Content-Type: text/plain; charset="UTF-8"

>
> On Tue, Nov 28, 2017 at 10:55 AM, Niklas Keller <me@kelunik.com> wrote:
> > it's the current practice to tag releases publicly two days before
> release
> > and then do the final QA phase. Could we please stop that?
> >
> > If there's a mistake that needs to be fixed and that's detected within
> these
> > two days, a re-tag needs to happen. If the old tag is deleted and a new
> > modified tag is published, all cloned Git repositories that already
> received
> > the old tag will keep the old tag and never receive the new tag unless
> the
> > old tag is manually removed first. That's problematic.
> >
> Agreed that tags shouldn't be moved once pushed, but is assigning a
> new version tag really that terrible?
>

No, that'd be fine, too. But IIRC there have been re-tags instead of new
tags before.


> Example: php-7.2.0 tag was just pushed by Remi for the release on
> Thursday.  If we do find a show-stopper bug, we can patch it and push
> php-7.2.0-pl1 or whatever.
>

That "or whatever" should probably be covered in the release process
document(s).


> Not a hill I need to die on either way, but I don't see the early push
> as necessarily a bad thing. Indeed, I know there are users who look
> forward to the early tag to start their builds ahead of time.  These
> parties then serve as a warning shot for that two-day cooling period.
> Could they build from branch before then? Yeah, but in at least one of
> those cases, I know that the presence of that tag is what got them
> doing it in the first place.


Correct, the tags are there, so people use them.

> If there won't be a re-tag but a new tag name instead, there's no reason
> to
> > not see the tagging as release instead of the release announcement two
> days
> > later.
> >
> Apart from the windows builds, and those pre-builders mentioned above.
>
> > If tags are necessary for the final QA phase and the QA phase should
> happen
> > before release, then these tags shouldn't be public, but in a private
> > repository instead. If tags aren't necessary, then the QA phase can use a
> > different tag or just a commit reference and the release announcement can
> > happen directly after the tagging.
> >
> Okay, that's a reasonable middle ground.  We could tag as
> php-X.Y.Z-something Tuesday, then tag again as php-X.Y.Z on Thursday.
> That would only add one step to the release process at the minor cost
> of having more tags. *shrug*
>

Why not just use the release branch instead of tags for that phase? I don't
think having a lot of these useless tags is a good thing.

Regards, Niklas

--001a114e59c827eaac055f0e6064--