Public Tags of Releases

  101180
November 28, 2017 15:55 me@kelunik.com (Niklas Keller)
Morning,

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.

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.

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.

Regards, Niklas
  101181
November 28, 2017 16:02 pthreads@pthreads.org (Joe Watkins)
Afternoon,

Tags are created in release branches, these branches should not be part of
any workflow other than our internal one.

It's problematic to tag other than publicly, anywhere we create these tags
is public and presumably would cause the same problem for those people who
choose to use release branches in their workflow.

Cheers
Joe

On 28 Nov 2017 4:55 pm, "Niklas Keller" <me@kelunik.com> wrote:

> Morning, > > 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. > > 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. > > 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. > > Regards, Niklas >
  101183
November 28, 2017 16:26 me@kelunik.com (Niklas Keller)
> > Afternoon, > > Tags are created in release branches, these branches should not be part of > any workflow other than our internal one. >
I'm not talking about branches, but tags. Updating these release branches doesn't matter and is totally fine, as these are normal branches and thus not deemed immutable. It's problematic to tag other than publicly, anywhere we create these tags
> is public and presumably would cause the same problem for those people who > choose to use release branches in their workflow. > > Cheers > Joe >
Regards, Niklas
  101188
November 28, 2017 17:16 pollita@php.net (Sara Golemon)
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? 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. 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.
> 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* -Sara
  101189
November 28, 2017 17:30 me@kelunik.com (Niklas Keller)
> > 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
  101190
November 28, 2017 19:29 ab@php.net (Anatol Belski)
Hi,

> -----Original Message----- > From: php@golemon.com [mailto:php@golemon.com] On Behalf Of Sara > Golemon > Sent: Tuesday, November 28, 2017 6:17 PM > To: Niklas Keller <me@kelunik.com> > Cc: PHP Internals <internals@lists.php.net>; Joe Watkins > <pthreads@pthreads.org>; Remi Collet <remi@php.net>; Anatol Belski > <ab@php.net> > Subject: Re: Public Tags of Releases > > 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? > > 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. > > 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. > > > 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* >
Tags and branches have a naming scheme, what only matters for a release right now is - branching off - tag - do tarball - do Windows build and zipball - announce By the current terms - there's no release until the announcement. Tags are a virtually internal thing. For a number of people the tarball is the actual release. The Windows builds are done from the tag, that's specific. The tarball is what includes generated files and goes to the mirrors, creating it before it's like putting a state under seal. Thanks to the fact it's open, more QA can be done. Thanks to the 2 day buffer, isues can be caught. Till now all the QA, except security issues, is an open process. The open process has a huge advantage of having lots of eyes on what is happening and helps not less than valgrind. Tags are an intermediate link in that chain. There should be one tag in the end, any other intermediate states are available from the release branch. Years after - there's still one tag for one release, clearly named. Regarding the technical side. There's `git fetch --prune --tags`, etc. Mirroring a repo assumes some level of expertise, it is not that terrible in the end. From my perspective, I don't see a real improvement in neither tagging in private or producing x different tags. From both technical and procedural side the current approach seems clear, flexible enough and good for QA at the same time. Regards Anatol
  101202
November 29, 2017 13:52 rowan.collins@gmail.com (Rowan Collins)
Hi,

I agree that tags should be treated as immutable, because that's what distinguishes them from branches. That's true of any VCS, but git has the added restriction that they're treated as global: tags from different remotes aren't tracked separately, they are all merged into the local namespace immediately.


On 28 November 2017 17:16:52 GMT+00:00, Sara Golemon <pollita@php.net> wrote:
>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*
The logical name for this would be "php-X.Y.Z-RC1": this is a Candidate revision which we believe is going to be tagged as Release. However, the current process abuses that term for late-stage test builds which are not actually release candidates. :( Another alternative would be to simply increment the build number on the rare occasions a tag is withdrawn: if 7.2.2 was a bad tag, just release 7.2.3 instead. Regards, -- Rowan Collins [IMSoP]
  101194
November 29, 2017 00:30 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> 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.
That's not how git is supposed to work? If you syncronize the repo you should get the new tag. If you cloned repo once and never update then of course you don't get new tag, but you also don't get the fix...
> 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
But we don't have private repository? We have security repo but this one is for security fixes and not for release work, in fact it doesn't even have to be up-to-date with release, it's only for keeping/exchanging security patches. -- Stas Malyshev smalyshev@gmail.com
  101195
November 29, 2017 02:22 pollita@php.net (Sara Golemon)
On Tue, Nov 28, 2017 at 7:30 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>> 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. > > That's not how git is supposed to work? If you syncronize the repo you > should get the new tag. If you cloned repo once and never update then of > course you don't get new tag, but you also don't get the fix... > Erm, actually no, it's not how git is supposed to work.
If you have an up to date checkout of php-src/master right now, it contains the php-7.2.0 tag. If Remi adds more commits (to fix something) and moves that tag to the new head of the PHP-7.2.0 branch and pushes it, then anyone who HADN'T YET synced php-src/master since this morning will get the new tag fine, but you never will (not with a normal `git pull`, anyway). This is because git will not change tags unless you explicitly tell it it's okay to. Moving git tags after they've been pushed to a remote (shared) repo is as much a sin as force pushing. It shouldn't be done. -Sara