# PHP 7.0.0 final RTM delay - Thread: https://externals.io/message/89383 - Original archive: https://news-web.php.net/php.internals/89383 - Started by Anatol Belski on 2015-11-24T16:38:35+00:00 - Messages: 41 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/89383.md?page=2 - 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 --- ## #89383 — Anatol Belski — 2015-11-24T16:38:35+00:00 URL: https://externals.io/message/89383#89383 Hi, based on the discussion of the last few days and the reached consent, the final date of the 7.0.0 RTM is shifted. RC8 is planned to appear on November 26th instead of GA. 7.0.0 RTM will follow shortly on December 3rd. The final release is going to be identical to RC8 with the exception of the bugs considered security relevant. Those still might be applied, if any. Looking straight forward to 7.0.0 RTM! Thanks everyone Anatol --- ## #89518 — Anatol Belski — 2015-12-02T07:34:10+00:00 URL: https://externals.io/message/89383#89518 · In reply to: #89383 Hi, > -----Original Message----- > From: Anatol Belski [mailto:weltling@outlook.de] > Sent: Tuesday, November 24, 2015 5:39 PM > To: internals@lists.php.net > Subject: [PHP-DEV] PHP 7.0.0 final RTM delay > > Hi, > > based on the discussion of the last few days and the reached consent, the final > date of the 7.0.0 RTM is shifted. RC8 is planned to appear on November 26th > instead of GA. 7.0.0 RTM will follow shortly on December 3rd. > > The final release is going to be identical to RC8 with the exception of the bugs > considered security relevant. Those still might be applied, if any. > > Looking straight forward to 7.0.0 RTM! > A short note to this is that due to the OpenSSL release on December 3rd that makes full sense to be included with the Windows builds, the PHP 7.0.0 announcement will most likely appear later afternoon. Regards Anatol --- ## #89520 — Sebastian Bergmann — 2015-12-02T08:01:03+00:00 URL: https://externals.io/message/89383#89520 · In reply to: #89518 Am 02.12.2015 um 08:34 schrieb Anatol Belski: > A short note to this is that due to the OpenSSL release on December 3rd that > makes full sense to be included with the Windows builds, the PHP 7.0.0 > announcement will most likely appear later afternoon. Do the Windows builds have to be available immediately when the sources of PHP 7.0.0 are released? --- ## #89521 — Anatol Belski — 2015-12-02T08:42:19+00:00 URL: https://externals.io/message/89383#89521 · In reply to: #89520 > -----Original Message----- > From: Sebastian Bergmann [mailto:sebastian@php.net] > Sent: Wednesday, December 2, 2015 9:01 AM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] PHP 7.0.0 final RTM delay > > Am 02.12.2015 um 08:34 schrieb Anatol Belski: > > […] > > Do the Windows builds have to be available immediately when the sources of > PHP 7.0.0 are released? Yes. Regards Anatol --- ## #89524 — Andi Gutmans — 2015-12-02T21:34:02+00:00 URL: https://externals.io/message/89383#89524 · In reply to: #89521 How’s it going? Are we golden? When do you plan on posting tomorrow? > > > > > > […] > of > > […] > Yes. > > Regards > > Anatol --- ## #89526 — Anatol Belski — 2015-12-02T22:04:52+00:00 URL: https://externals.io/message/89383#89526 · In reply to: #89524 Hi Andi, > -----Original Message----- > From: Andi Gutmans [mailto:andi@zend.com] > Sent: Wednesday, December 2, 2015 10:34 PM > To: Anatol Belski > Cc: Sebastian Bergmann ; internals@lists.php.net > Subject: Re: [PHP-DEV] PHP 7.0.0 final RTM delay > > How’s it going? Are we golden? > When do you plan on posting tomorrow? > OpenSSL is releasing on 3rd between 1pm and 5pm UTC and contains some security fixes. As soon it is out, it'll need some time to build the bins and to test - that the normal practice when we collide with some library like OpenSSL. So the announcement will most likely shift into the later afternoon, still same day by UTC and most other time zones. That's the plan, nothing else can really stop it. Regards Anatol --- ## #89529 — Jan Ehrhardt — 2015-12-03T00:53:05+00:00 URL: https://externals.io/message/89383#89529 · In reply to: #89526 "Anatol Belski" in php.internals (Wed, 2 Dec 2015 23:04:52 +0100): > OpenSSL is releasing on 3rd between 1pm and 5pm UTC and contains some > security fixes. As soon it is out, it'll need some time to build the bins > and to test - that the normal practice when we collide with some library > like OpenSSL. So the announcement will most likely shift into the later > afternoon, still same day by UTC and most other time zones. That's the > plan, nothing else can really stop it. Will you include cUrl 7.46.0 as well? It was released a few hours ago and has no issues in upgrading AFAIK. Libxml2 2.9.3 was also released recently. I did not encouter any problems with the update from 2.9.2 -- Jan --- ## #89530 — Sebastian Bergmann — 2015-12-03T05:51:01+00:00 URL: https://externals.io/message/89383#89530 · In reply to: #89521 Am 02.12.2015 um 09:42 schrieb Anatol Belski: > > […] > Yes. http://git.php.net/?p=php-src.git;a=blob;f=README.RELEASE_PROCESS currently reads "Ensure that Windows builds will work before packaging" in the "General notes and tips" section and then later in the "Rolling a stable release" section "Once the release has been tagged, contact the PHP Windows development team (internals-win@lists.php.net) so that Windows binaries can be created." I do not think that this means that the release of the source tarball must wait for the availability of the Windows binaries. In fact, step 2g of "Getting the stable release announced" explains what to do when the Windows binaries are not available at the time of release. Please do not get me wrong: I appreciate what Microsoft in general and you, Anatol, as well as Pierre in particular have done for PHP. But no vendor -- neither Microsoft nor Red Hat nor whoever else rolls binary distributions of PHP -- should have the power to delay a release in my opinion. --- ## #89531 — Remi Collet — 2015-12-03T06:57:20+00:00 URL: https://externals.io/message/89383#89531 · In reply to: #89530 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 03/12/2015 06:51, Sebastian Bergmann a écrit : > Am 02.12.2015 um 09:42 schrieb Anatol Belski: > > […] > I do not think that this means that the release of the source > tarball must wait for the availability of the Windows binaries. I agree, this can't be a blocker. But, in the past, downstream build done "before" announcement have allowed us to detect and don't distribute broken versions. e.g. - - a recent 7.0.0RC was retagged because of huge regression in the session management - - a recent 5.6 released was repackaged because of missing files in the "not-yet-official" archive So, waiting a "few" hours is not a really big issue. Of course, as there is a huge expectation for this version, and internet have already start talking about it, we should really announce it today. My 0.02€ Remi. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlZf59AACgkQYUppBSnxahh05QCdEr0C86UK0/Sjx7whGEuIsYv2 NYQAoLZVhy/Yu4xCiOToy5ERqJPslmL3 =aXN3 -----END PGP SIGNATURE --- ## #89532 — Andi Gutmans — 2015-12-03T07:42:43+00:00 URL: https://externals.io/message/89383#89532 · In reply to: #89530 > > > Please do not get me wrong: I appreciate what Microsoft in general > and you, Anatol, as well as Pierre in particular have done for PHP. > But no vendor -- neither Microsoft nor Red Hat nor whoever else > rolls binary distributions of PHP -- should have the power to delay > a release in my opinion. Ditto. Never remember any such thing in PHP history. Binary builds should not be a blocker to releases. Not Windows/MSFT, Zend, Red Hat or anyone... Andi --- ## #89533 — Anatol Belski — 2015-12-03T08:09:47+00:00 URL: https://externals.io/message/89383#89533 · In reply to: #89530 Hi Sebastian, > -----Original Message----- > From: Sebastian Bergmann [mailto:sebastian@php.net] > Sent: Thursday, December 3, 2015 6:51 AM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] PHP 7.0.0 final RTM delay > > Am 02.12.2015 um 09:42 schrieb Anatol Belski: > > […] > > http://git.php.net/?p=php-src.git;a=blob;f=README.RELEASE_PROCESS > currently reads > > "Ensure that Windows builds will work before packaging" > > in the "General notes and tips" section and then later in the "Rolling a stable > release" section > > "Once the release has been tagged, contact the PHP Windows > development team (internals-win@lists.php.net) so that Windows > binaries can be created." > > I do not think that this means that the release of the source tarball must wait > for the availability of the Windows binaries. > In fact, step 2g of "Getting the stable release announced" explains what to do > when the Windows binaries are not available at the time of release. > > Please do not get me wrong: I appreciate what Microsoft in general and you, > Anatol, as well as Pierre in particular have done for PHP. > But no vendor -- neither Microsoft nor Red Hat nor whoever else rolls binary > distributions of PHP -- should have the power to delay a release in my opinion. > Thanks for your notes. I lean on the current practice, which is indeed continues already for some years, that we deliver the whole set of packages prior the release announcement. The RELEASE_PROCESS document is unfortunately not 100% in sync with everything. But indeed I cannot remember a case where a release were done without the care about the eco system. Particularly Windows packages are being linked directly from the release announcement for a while. Users know that and depend explicitly on us telling - release ready, you can use it. Lucky RedHat users have Remi's repo then :) At the end of the day, the release is made for the users. Most of users won't even think about building from sources. It would sound really weird to send a release which is unavailable to big mass of them today, even for a release with less importance. And especially with the 7.0.0 matter, where people was telling they'll even take it right at the day zero. But even if not - doing so would move some of users into the second class suddenly, quite rightless. I would just ask for some patience, as mentioned before - today by UTC the announcement is going out. It is still December 3rd as planned. That's why I was sending the awareness about the late UTC afternoon today. Thanks Anatol --- ## #89534 — Anatol Belski — 2015-12-03T08:20:04+00:00 URL: https://externals.io/message/89383#89534 · In reply to: #89529 Hi Jan, > -----Original Message----- > From: Jan Ehrhardt [mailto:phpdev@ehrhardt.nl] > Sent: Thursday, December 3, 2015 1:53 AM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] PHP 7.0.0 final RTM delay > > "Anatol Belski" in php.internals (Wed, 2 Dec 2015 23:04:52 +0100): > > […] > > Will you include cUrl 7.46.0 as well? It was released a few hours ago and has no > issues in upgrading AFAIK. > > Libxml2 2.9.3 was also released recently. I did not encouter any problems with > the update from 2.9.2 > -- The regular library upgrades are not planned for 7.0.0, but will take for the later versions. OpenSSL however is security conditioned. Regards Anatol --- ## #89535 — Anatol Belski — 2015-12-03T08:26:46+00:00 URL: https://externals.io/message/89383#89535 · In reply to: #89532 Hi Andi, > -----Original Message----- > From: Andi Gutmans [mailto:andi@zend.com] > Sent: Thursday, December 3, 2015 8:43 AM > To: Sebastian Bergmann > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] PHP 7.0.0 final RTM delay > > > > […] wrote: > > […] > > Ditto. Never remember any such thing in PHP history. Binary builds should not be > a blocker to releases. Not Windows/MSFT, Zend, Red Hat or anyone... > No one was talking about a "blocker", everything looks good for today. A blocker colud be a critical issue, which by chance are often discovered short before release by the suspects you mentioned. No such issues are known ATM. Regards Anatol --- ## #89536 — Sebastian Bergmann — 2015-12-03T08:38:33+00:00 URL: https://externals.io/message/89383#89536 · In reply to: #89535 Am 03.12.2015 um 09:26 schrieb Anatol Belski: > No one was talking about a "blocker", everything looks good for today. A > blocker colud be a critical issue, which by chance are often discovered > short before release by the suspects you mentioned. No such issues are known > ATM. The decision to wait for a release of a third-party library before the Windows binaries are built is a blocker as it puts the release of PHP on hold. --- ## #89537 — Zeev Suraski — 2015-12-03T08:55:12+00:00 URL: https://externals.io/message/89383#89537 · In reply to: #89533 > > > I would just ask for some patience, as mentioned before - today by UTC the > announcement is going out. It is still December 3rd as planned. That's why I > was sending the awareness about the late UTC afternoon today. > Anatol, We're not dealing with tax forms that have to make it in by midnight UTC but rather with humans. Humans who are very excited and literally can't wait to celebrate the release of PHP - a lot more so as an event than necessarily downloading and installing it right away (if that's what they cared about they could do it already). Releasing it now would mean most of the world gets to actually celebrate it on Dec 3rd, instead of turning it into a frustrating waiting day. I find it hard to imagine people having an issue with us saying the Windows binaries would be coming soon. That's why all in all, I think it's a mistake not to push it out as early in the day as possible, in other words - now. I also think that in general we shouldn't wait with source releases for binary release - but specifically in this case, it's too minor a thing in my opinion to delay a historical release like that of PHP 7.0.0. My 2c. Zeev --- ## #89539 — Pierre Joye — 2015-12-03T10:11:25+00:00 URL: https://externals.io/message/89383#89539 · In reply to: #89531 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Le 03/12/2015 06:51, Sebastian Bergmann a écrit : > > […] > > > […] > > I agree, this can't be a blocker. > > But, in the past, downstream build done "before" announcement have > allowed us to detect and don't distribute broken versions. On spot. Exactly that. And testing that latest openssl releases (which includes security fixes) work well with a php release looks like a blocker to me, even more if it only means a couple of hours. We had cases where the delay was days not hours, but we did not wait. > e.g. > - - a recent 7.0.0RC was retagged because of huge regression in the > session management > - - a recent 5.6 released was repackaged because of missing files in the > "not-yet-official" archive > > So, waiting a "few" hours is not a really big issue. > > Of course, as there is a huge expectation for this version, and > internet have already start talking about it, we should really > announce it today. --- ## #89540 — Pierre Joye — 2015-12-03T10:17:24+00:00 URL: https://externals.io/message/89383#89540 · In reply to: #89537 Hi Zeev, > > > […] > > Anatol, > > We're not dealing with tax forms that have to make it in by midnight UTC but rather with humans. Humans who are very excited and literally can't wait to celebrate the release of PHP - a lot more so as an event than necessarily downloading and installing it right away (if that's what they cared about they could do it already). > > Releasing it now would mean most of the world gets to actually celebrate it on Dec 3rd, instead of turning it into a frustrating waiting day. I find it hard to imagine people having an issue with us saying the Windows binaries would be coming soon. That's why all in all, I think it's a mistake not to push it out as early in the day as possible, in other words - now. > > I also think that in general we shouldn't wait with source releases for binary release - but specifically in this case, it's too minor a thing in my opinion to delay a historical release like that of PHP 7.0.0. The releases must be kept on hold until these binaries (and other are done in the same time btw) are validated. See it as part of the QA. As Remi mentioned, many issues have be caught during this process. If it was only about delivering binaries, a day later will never be a problem. But it is not the case. The case we are referring toi is to avoid to have to do a fast patch release to work around an issue we could have seen by validating the binaries.Simple. -- Pierre @pierrejoye | http://www.libgd.org --- ## #89542 — Anatol Belski — 2015-12-03T10:44:05+00:00 URL: https://externals.io/message/89383#89542 · In reply to: #89537 Hi Zeev, > -----Original Message----- > From: Zeev Suraski [mailto:zeev@zend.com] > Sent: Thursday, December 3, 2015 9:55 AM > To: Anatol Belski > Cc: Sebastian Bergmann ; internals@lists.php.net > Subject: Re: [PHP-DEV] PHP 7.0.0 final RTM delay > > > > […] > > Anatol, > > We're not dealing with tax forms that have to make it in by midnight UTC but > rather with humans. Humans who are very excited and literally can't wait to > celebrate the release of PHP - a lot more so as an event than necessarily > downloading and installing it right away (if that's what they cared about they > could do it already). > > Releasing it now would mean most of the world gets to actually celebrate it on > Dec 3rd, instead of turning it into a frustrating waiting day. I find it hard to > imagine people having an issue with us saying the Windows binaries would be > coming soon. That's why all in all, I think it's a mistake not to push it out as early > in the day as possible, in other words - now. > > I also think that in general we shouldn't wait with source releases for binary > release - but specifically in this case, it's too minor a thing in my opinion to delay > a historical release like that of PHP 7.0.0. > > My 2c. > My red wine is already cooling for two days, your preferential drink for sure, too. The moment is big. But how human it wants ever to be, it is hardly applicable to the the job of delivering a release, even today. We should not let us to hype but do a solid delivery with everything that belongs to it at the current time. Acting any other way can get dangerous in the technical perspective and specifically today it would be explicitly unfair to a part of the community. Both things are bad. That's why I would prefer rather to keep the heads cold and to follow the process that is proven to deliver successful releases, then we can be sure others have a real reason to overhype. Regards Anatol --- ## #89543 — Anatol Belski — 2015-12-03T10:44:49+00:00 URL: https://externals.io/message/89383#89543 · In reply to: #89536 Hi Sebastian, > -----Original Message----- > From: Sebastian Bergmann [mailto:sebastian@php.net] > Sent: Thursday, December 3, 2015 9:39 AM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] PHP 7.0.0 final RTM delay > > Am 03.12.2015 um 09:26 schrieb Anatol Belski: > > […] > > The decision to wait for a release of a third-party library before the Windows > binaries are built is a blocker as it puts the release of PHP on hold. > IMHO offering a secure release which also fits with users expectations, doesn't break the current release practice and comes within the acceptable time frame is professionally accountable. Anatol --- ## #89544 — Sebastian Bergmann — 2015-12-03T10:58:42+00:00 URL: https://externals.io/message/89383#89544 · In reply to: #89543 Am 03.12.2015 um 11:44 schrieb Anatol Belski: > IMHO offering a secure release which also fits with users expectations I would agree if this were about the release itself, PHP's sourcecode. It is not. It is about a binary. But I will shut up now. --- ## #89545 — bjorn.x.larsson@telia.com — 2015-12-03T11:01:26+00:00 URL: https://externals.io/message/89383#89545 · In reply to: #89542 Den 2015-12-03 kl. 11:44, skrev Anatol Belski: > Hi Zeev, > > > […] > My red wine is already cooling for two days, your preferential drink for sure, too. The moment is big. But how human it wants ever to be, it is hardly applicable to the the job of delivering a release, even today. We should not let us to hype but do a solid delivery with everything that belongs to it at the current time. Acting any other way can get dangerous in the technical perspective and specifically today it would be explicitly unfair to a part of the community. Both things are bad. That's why I would prefer rather to keep the heads cold and to follow the process that is proven to deliver successful releases, then we can be sure others have a real reason to overhype. > > Regards > > Anatol > Having some red wine on the cooling seems like a very good idea, especially in combination with a cool head ;-). And thanks for a very professional job getting #PHP7 out of the door! Regards //Björn Larsson --- ## #89546 — francois@php.net — 2015-12-03T11:02:49+00:00 URL: https://externals.io/message/89383#89546 · In reply to: #89537 Le 03/12/2015 09:55, Zeev Suraski a écrit : > Releasing it now would mean most of the world gets to actually > celebrate it on Dec 3rd, instead of turning it into a frustrating > waiting day. I find it hard to imagine people having an issue with us > saying the Windows binaries would be coming soon. That's why all in > all, I think it's a mistake not to push it out as early in the day as > possible, in other words - now. I also think that in general we > shouldn't wait with source releases for binary release - but > specifically in this case, it's too minor a thing in my opinion to > delay a historical release like that of PHP 7.0.0. My 2c. Zeev +1. It's 23:59 pm in Auckland, NZ now. The world has entered Dec, 4th. François --- ## #89547 — Pierre Joye — 2015-12-03T11:10:19+00:00 URL: https://externals.io/message/89383#89547 · In reply to: #89544 > Am 03.12.2015 um 11:44 schrieb Anatol Belski: > > […] > > I would agree if this were about the release itself, PHP's sourcecode. > It is not. It is about a binary. But I will shut up now. In my world, we build softwares from sources, then we may found issues. We patch the sources to fix them and make everything work together smoothly. In other words, either we totally failed to explain the QA part of this process or you focus mainly on "windows blah, windows there" part of this thing. And that windows is and always been part of the release process is nothing new. Yes, 7 is big, but that should not affect the quality of our releases, the sources and the ability to use these sources with the libraries out there. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #89548 — francois@php.net — 2015-12-03T11:13:36+00:00 URL: https://externals.io/message/89383#89548 · In reply to: #89540 Le 03/12/2015 11:17, Pierre Joye a écrit : > The releases must be kept on hold until these binaries (and other are > done in the same time btw) are validated. See it as part of the QA. As > Remi mentioned, many issues have be caught during this process. If it > was only about delivering binaries, a day later will never be a > problem. But it is not the case. The case we are referring toi is to > avoid to have to do a fast patch release to work around an issue we > could have seen by validating the binaries.Simple. I understand your pov and I agree that windows binaries should be ready when announcing the release. But, IMO, everything should have been 'frozen' 2 or 3 days ago and a new openssl release or any other 3rd party software, even tagged 'security fixes' shouldn't have disturbed the process. Or the change is hot enough to delay the date again, but that's another process. Sorry to say that, as it doesn't remove anything to my respect for the huge work you did, but It's now Dec, 4th in more and more locations in the world and PHP 7 is not released yet ! Zeev is right, nobody cares about UTC in such case. Regards François --- ## #89549 — Sebastian Bergmann — 2015-12-03T11:14:59+00:00 URL: https://externals.io/message/89383#89549 · In reply to: #89547 Am 03.12.2015 um 12:10 schrieb Pierre Joye: > In my world, we build softwares from sources, then we may found > issues. We patch the sources to fix them and make everything work > together smoothly. Are you suggesting that PHP 7.0.0 will be changed, re-tagged, and then released without a new release candidate if you find a problem building it for Windows? --- Next page: https://externals.io/message/89383.md?page=2