# Public Tags of Releases - Thread: https://externals.io/message/101180 - Original archive: https://news-web.php.net/php.internals/101180 - Started by Niklas Keller on 2017-11-28T15:55:50+00:00 - Messages: 14 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #101180 — Niklas Keller — 2017-11-28T15:55:50+00:00 URL: https://externals.io/message/101180#101180 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 — Joe Watkins — 2017-11-28T16:02:09+00:00 URL: https://externals.io/message/101180#101181 · In reply to: #101180 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 > 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 --- ## #101182 — Joe Watkins — 2017-11-28T16:04:26+00:00 URL: https://externals.io/message/101180#101182 Oh and private repositories suck, we already have a headache with security fixes because of strange flow and secrecy, we simply don't need or want more of that. Cheers Joe 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 > 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 — Niklas Keller — 2017-11-28T16:26:02+00:00 URL: https://externals.io/message/101180#101183 · In reply to: #101181 > > 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 — Sara Golemon — 2017-11-28T17:16:52+00:00 URL: https://externals.io/message/101180#101188 · In reply to: #101180 > 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 — Niklas Keller — 2017-11-28T17:30:30+00:00 URL: https://externals.io/message/101180#101189 · In reply to: #101188 > > > > […] > release > > […] > these > > […] > received > > […] > the > > […] > 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 > > […] > days > > […] > Apart from the windows builds, and those pre-builders mentioned above. > > > […] > happen > > […] > 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 — Anatol Belski — 2017-11-28T19:29:41+00:00 URL: https://externals.io/message/101180#101190 · In reply to: #101188 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 > Cc: PHP Internals ; Joe Watkins > ; Remi Collet ; Anatol Belski > > Subject: Re: Public Tags of Releases > > > > […] > 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. > > > […] > Apart from the windows builds, and those pre-builders mentioned above. > > > […] > 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 --- ## #101194 — Stanislav Malyshev — 2017-11-29T00:30:49+00:00 URL: https://externals.io/message/101180#101194 · In reply to: #101180 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 — Sara Golemon — 2017-11-29T02:22:03+00:00 URL: https://externals.io/message/101180#101195 · In reply to: #101194 > > […] > > 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 --- ## #101201 — Jan Ehrhardt — 2017-11-29T11:09:55+00:00 URL: https://externals.io/message/101180#101201 · In reply to: #101190 Anatol Belski in php.internals (Tue, 28 Nov 2017 19:29:41 +0000): >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. FWIW: I am using the zip's at github, like https://github.com/php/php-src/archive/php-7.2.0.zip -- Jan --- ## #101202 — Rowan Collins — 2017-11-29T13:52:17+00:00 URL: https://externals.io/message/101180#101202 · In reply to: #101188 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. >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] --- ## #101203 — johannes@schlueters.de — 2017-11-29T14:37:37+00:00 URL: https://externals.io/message/101180#101203 · In reply to: #101201 > FWIW: I am using the zip's at github, like > https://github.com/php/php-src/archive/php-7.2.0.zip Contrary to "official" release tarballs those don't contain generated parsers etc. thus behavior might be different i.e. due to different bison versions being used. (sohuldn't be, but happened in the past) Also they don't contain ready to use configure scripts (for unix-like systems) thus a (Linux/Unix/Mac) user needs right versions of auto tools. johannes --- ## #101204 — lists@rhsoft.net — 2017-11-29T14:43:25+00:00 URL: https://externals.io/message/101180#101204 · In reply to: #101203 Am 29.11.2017 um 15:37 schrieb Johannes Schlüter: > > > […] > > Contrary to "official" release tarballs those don't contain generated > parsers etc. thus behavior might be different i.e. due to different > bison versions being used. (sohuldn't be, but happened in the past) > Also they don't contain ready to use configure scripts (for unix-like > systems) thus a (Linux/Unix/Mac) user needs right versions of auto > tools same applies to compilers, compiler flags and system library versions anyways # rebuild 'data_file.c' from current system libmagic starting with PHP 7.2 and when /usr/bin/php is installed %if "%{version}" >= "7.2.0" if [ -f /usr/bin/php ]; then /usr/bin/php ext/fileinfo/create_data_file.php /usr/share/misc/magic.mgc > ext/fileinfo/data_file.c fi %endif # generate zend-vm when /usr/bin/php is installed %if "%{version}" >= "7.2.0" if [ -f /usr/bin/php ]; then /usr/bin/php Zend/zend_vm_gen.php --with-vm-kind=HYBRID fi %else if [ -f /usr/bin/php ]; then /usr/bin/php Zend/zend_vm_gen.php --with-vm-kind=CALL fi %endif # force use of system libtool and regenerate configure scripts cat `aclocal --print-ac-dir`/{libtool,ltoptions,ltsugar,ltversion,lt~obsolete}.m4 >> aclocal.m4 libtoolize --force --copy --quiet cat `aclocal --print-ac-dir`/{libtool,ltoptions,ltsugar,ltversion,lt~obsolete}.m4 >build/libtool.m4 %if "%{version}" >= "7.2.0" touch configure.ac %else touch configure.in %endif ./buildconf --force --- ## #101205 — johannes@schlueters.de — 2017-11-29T14:52:05+00:00 URL: https://externals.io/message/101180#101205 · In reply to: #101204 > Am 29.11.2017 um 15:37 schrieb Johannes Schlüter: > > […] > same applies to compilers, compiler flags and system library > versions  > anyways > This is true, but usually has less impact. bison&co historically are less stable than compiler support for language features we use. Third party libraries used in extensions are another complex story. Which is why we bundle some libs. johannes