Hi, > -----Original Message----- > From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara > Golemon > Sent: Tuesday, November 28, 2017 6:17 PM > To: Niklas Keller <m...@kelunik.com> > Cc: PHP Internals <internals@lists.php.net>; Joe Watkins > <pthre...@pthreads.org>; Remi Collet <r...@php.net>; Anatol Belski > <a...@php.net> > Subject: Re: Public Tags of Releases > > On Tue, Nov 28, 2017 at 10:55 AM, Niklas Keller <m...@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
