Re: [PHP-DEV] PHP 5.3 - end of live schedule
Hi Internals, Why not EOL until Zend has it's ZCE program up to date with the latest version? Kind regards, Chris van Dam Op 11-12-12 02:29 schreef Johannes Schlüter johan...@php.net: On Tue, 2012-12-11 at 08:55 +0900, Yasuo Ohgaki wrote: 2012/12/10 Adam Harvey ahar...@php.net: On 10 December 2012 18:58, Johannes Schlüter johan...@php.net wrote: As of this date the 5.3 branch will go to extended support and should receive security fixes only. Releases will be made based on need. Please mind that the above schedule is tentative and unpredictable events might change this. Comments? I think there is no consensus of EOL of 5.3 from last discussion as Pierre mentioned. In the thread [RFC] discussions, about a 5.3 EOL mostly supported option #1 from the RFC, some were convinced and changed their opinion for #1, one wished for some LTS kind of model (which is an independent thing which means replacing the current release model, aka nowadays relevant for 5.5) Some people commented about waiting for 5.5 but not as much. Also the proposer of that RFC mentioned this had to be decided now depending on 5.4's release, but apparently didn't see need to formalize this by a vote which I also interpreted(!) as part of a consensus. At the very least, I think we should keep full support going until 5.5.0 final is out, which it strikes me probably won't be in February at our current rate. Anyway, I'm +1 for extending 5.3 EOL at least until 5.5.0 release. Well, people don't trust .0 versions, so we then should wait for 5.5.1 or 5.5.2 ... but by then 5.6 will already be in development, so why not wait for 5.6? But more seriously: 5.3 won't stop working and will still receive critical fixes for at least a year. Users will also face less risk while updating that a fix broke something by accident. As a recent example take a look at commit 6dff07 (Fixed bug #63512 parse_ini_file() with INI_SCANNER_RAW removes quotes from value). This change slightly changes the behavior. People might treat the current behavior, which was introduced while fixing #51094 for 5.3.15 as feature even though (I assume) most users would see #51094 and #63512, as clear bugs. Such changes force people to verify each and every release. If we limit ourselves to critical issues we a) reduce the risk of adding new bugs (like #63512) b) make the verification process for users simpler as less things in the code change. While, yes, there might be a few more bugs, but they are at least documented in the bug tracker and fixes and different work-arounds exist. (and if too many people stumble over it, it can still be escalated and become critical) A bit related rant: Looking at the commit times of some merges it seems unlikely that all changes are actually tested in all branches. When there is less than two minutes between a commit to 5.3 and merge to 5.4, 5.5 and master I assume that often the only test is about merge conflicts -- not even a compile test. Of course people might do some manual things outside git, do merges with --no-commit first and later commit or do some rewrite in between ... but I assume the less branches we have the higher the percentage of tested branches is (pessimistically: from 25% to 33.3%) How about announce 5.3 EOL in 5.5 RC release notes? RCs don't reach the same audience. PHP 5.3.x release notes need it. 5.5.0-final release notes will certainly receive our boilerplate All users are suggested to update snippet, maybe a bit extended. Which is also why I hope we reach an agreement before release 5.3.20 on Thursday next week. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php E-mail disclaimer Nederlands De informatie verzonden met dit e-mailbericht is vertrouwelijk en kan wettelijk voorbehouden zijn. Het is uitsluitend bestemd voor de geadresseerde. Gebruik van deze informatie door anderen dan de geadresseerde en zij die gerechtigd zijn daarvan kennis te nemen is verboden. Trace staat niet in voor de juiste en volledige overbrenging van de inhoud van een verzonden e-mail, noch voor tijdige ontvangst daarvan. E-mail disclaimer English The information contained in this communication is confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. The use of it by others is prohibited. Trace is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 - end of live schedule
Hi, 2012/12/11 Johannes Schlüter johan...@php.net: Well, people don't trust .0 versions, so we then should wait for 5.5.1 or 5.5.2 ... but by then 5.6 will already be in development, so why not wait for 5.6? +1 It's much better! -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 - end of live schedule
On Tue, Dec 11, 2012 at 11:30 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi, 2012/12/11 Johannes Schlüter johan...@php.net: Well, people don't trust .0 versions, so we then should wait for 5.5.1 or 5.5.2 ... but by then 5.6 will already be in development, so why not wait for 5.6? +1 It's much better! what's about: - announce 5.3 EOL plan with 5.5 final release then: - EOL by release of php-next (a year later) or - EOL by release of php-next+1 (two years later) depending on which option got accepted. -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 - end of live schedule
On Tue, Dec 11, 2012 at 12:48 PM, Pierre Joye pierre@gmail.com wrote: what's about: - announce 5.3 EOL plan with 5.5 final release then: - EOL by release of php-next (a year later) or - EOL by release of php-next+1 (two years later) depending on which option got accepted. In all these cases we are going to support 3 branches in parallel, is that really what we want ? I would be happy to see 5.3 in security mode only before the realase of 5.5. Also, I wouldn't make a connection between release of the next version with the EOL, as the next version can always be delayed and we want to limit the support time of old versions to focus on stable and php-next development. Kaplan
Re: [PHP-DEV] PHP 5.3 - end of live schedule
hi, On Tue, Dec 11, 2012 at 12:30 PM, Lior Kaplan lio...@zend.com wrote: On Tue, Dec 11, 2012 at 12:48 PM, Pierre Joye pierre@gmail.com wrote: what's about: - announce 5.3 EOL plan with 5.5 final release then: - EOL by release of php-next (a year later) or - EOL by release of php-next+1 (two years later) depending on which option got accepted. In all these cases we are going to support 3 branches in parallel, is that really what we want ? I would be happy to see 5.3 in security mode only before the realase of 5.5. Also, I wouldn't make a connection between release of the next version with the EOL, as the next version can always be delayed and we want to limit the support time of old versions to focus on stable and php-next development. That's the only reason why we did not did vote on this EOL before, to do it with 5.5... -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 - end of live schedule
On 12/10/12 8:32 AM, Johannes Schlüter wrote: Hi, On Mon, 2012-12-10 at 14:10 +0100, Pierre Joye wrote: There was no consensus, I am not sure where you get the idea. By spending the time to go through the thread, taking the opinions stated there, filtering out side discussions (like LTS based release models etc) evaluating it (partly subjective) and summarizing it as in the mail starting this thread. However, we discussed to wait a bit before proposing the RFC to clearly and cleanly define the EOL of 5.3. Your message saying 5.4 was released on March, 1st. That's why I asked this question now while it should have been done before. which is one of the last from the thread doesnt' sound like delaying for additional 3/4 years for a decision. I will clean up this RFC and call for vote later this week (most likely tomorrow). It is very important to follow this step instead of simply say, hey, I will go down this way because I like it ;-) feel free to do what you want. The delay is way too short for 3rd parties to adapt. If people can provide reasons to extend it I'm open to hear those. johannes As a data point, Drupal 8 is slated to target PHP 5.3. Probably 5.3.10 and up, with release targeted in the second half of 2013. That is based primarily on our investigation into what is actually shipping in Linux distributions, and what the market looks like it will probably look like. There's still plenty of places deploying Drupal on PHP 5.2, even though I try to avoid using them myself, including large enterprise hosting services. (I'd love to be pushing to PHP 5.4 faster, but the lag time for distributions and hosts is painful.) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.3 - end of live schedule
Hi, after 5.4.0 was released we had a discussion on 5.3 EOL. Even though it wasn't properly documented the overall consensus was to go with option one from https://wiki.php.net/rfc/php53eol One year with bugs fixes followed by one year with security fixes only So as quick reminder and help for the ones who don't want to do the maths about our current release schedule themselves the schedule looks like this: December 20th -- Release PHP 5.3.20 January 2nd -- Branch of PHP 5.3.21 January 17th -- Release PHP 5.3.21 January 30th -- Branch of PHP 5.3.22 February 14th -- Release PHP 5.3.22 As of this date the 5.3 branch will go to extended support and should receive security fixes only. Releases will be made based on need. Please mind that the above schedule is tentative and unpredictable events might change this. Comments? johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 - end of live schedule
On 10 December 2012 18:58, Johannes Schlüter johan...@php.net wrote: As of this date the 5.3 branch will go to extended support and should receive security fixes only. Releases will be made based on need. Please mind that the above schedule is tentative and unpredictable events might change this. Comments? At the very least, I think we should keep full support going until 5.5.0 final is out, which it strikes me probably won't be in February at our current rate. Beyond that, I don't particularly want to create a rod for our own backs ($DEITY knows, _I'm_ useless at merging across branches, as you all know), but I wonder if 5.3 might need a bit longer in one form or another. RHEL 6, Debian 6, Ubuntu 12.04 (not the latest stable version, unlike the others, but the LTS version), Mac OS X 10.8 (and many of the derivatives of these distros, particularly RHEL) are all shipping PHP 5.3 packages by default. As a result, I think the odds are that developers are likely to develop and deploy applications on PHP 5.3 for quite some time to come. (Plus, 5.3 had most of the big headline features of the last few years — a lot of people will consider it good enough.) I'm not suggesting we necessarily extend full support, but I wonder if one year of critical bug fixes and security updates will be enough. Adam, who will now take his 2¢ and do something useful, like making the MySQL changes from last week. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 - end of live schedule
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 10.12.2012 13:21, schrieb Adam Harvey: RHEL 6, Debian 6, Ubuntu 12.04 (not the latest stable version, unlike the others, but the LTS version), Mac OS X 10.8 (and many of the derivatives of these distros, particularly RHEL) are all shipping PHP 5.3 packages by default. SLES 11 only upgraded to php 5.3 with SP2 and will drop 5.2 support in Service Pack 3. Enterprise Distributions generally make it easier to keep old stuff than allowing bleeding edge code like PHPUnit to run. - -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: l...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlDF2b8ACgkQCs1dsHJ/X7CjngCgzq2JboyvQZp72jdIanS9ilvg cwYAn3hERduQBAcUXWS2jqSLFs82WuzX =XNST -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 - end of live schedule
Hi, On Mon, 2012-12-10 at 20:21 +0800, Adam Harvey wrote: At the very least, I think we should keep full support going until 5.5.0 final is out, which it strikes me probably won't be in February at our current rate. Beyond that, I don't particularly want to create a rod for our own backs ($DEITY knows, _I'm_ useless at merging across branches, as you all know), but I wonder if 5.3 might need a bit longer in one form or another. RHEL 6, Debian 6, Ubuntu 12.04 (not the latest stable version, unlike the others, but the LTS version), Mac OS X 10.8 (and many of the derivatives of these distros, particularly RHEL) are all shipping PHP 5.3 packages by default. As a result, I think the odds are that developers are likely to develop and deploy applications on PHP 5.3 for quite some time to come. (Plus, 5.3 had most of the big headline features of the last few years — a lot of people will consider it good enough.) I'm not suggesting we necessarily extend full support, but I wonder if one year of critical bug fixes and security updates will be enough. In my opinion key for this is PR. Get people to migrate to 5.4. We are still flexible to interpret what critical issues are, and to merge and release those. (And extend that time if we see too little migration) For distributions at least Ondřej supported this option from Debian perspective. In my opinion distributions in fact would be happy with this. all they want are critical fixes in their stable and backport only this. The more we prefilter the simpler for them. Please also mind: Most bugs exist for years, most are older than 5.3. If they lived with those on 5.2 they are no stoppers to migrate away from there. The biggest category of 5.3-only bugs is around gc. PHP 5.3 won't stop working and for operations there is no big difference after February 2013 ... rather less risk of getting bug fixes which, by accident, change behavior. Therefore after February 2013 users updating need less validation when updating. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 - end of live schedule
On 10 December 2012 20:51, Johannes Schlüter johan...@php.net wrote: Hi, On Mon, 2012-12-10 at 20:21 +0800, Adam Harvey wrote: I'm not suggesting we necessarily extend full support, but I wonder if one year of critical bug fixes and security updates will be enough. In my opinion key for this is PR. Get people to migrate to 5.4. We are still flexible to interpret what critical issues are, and to merge and release those. (And extend that time if we see too little migration) I couldn't agree more. For distributions at least Ondřej supported this option from Debian perspective. In my opinion distributions in fact would be happy with this. all they want are critical fixes in their stable and backport only this. The more we prefilter the simpler for them. To be honest, Debian isn't really the distribution I'm worried about. Ondřej does good work, and Debian Wheezy has PHP 5.4 and isn't miles off, it seems. RHEL and Ubuntu are mostly the ones I'm thinking of here — RHEL 7 is supposed to be out in the second half of next year, but history (and my own experience both in supporting users and dealing with vendors) suggests that RHEL users are slow to upgrade. Ubuntu won't have another LTS release until 2014. Please also mind: Most bugs exist for years, most are older than 5.3. If they lived with those on 5.2 they are no stoppers to migrate away from there. The biggest category of 5.3-only bugs is around gc. PHP 5.3 won't stop working and for operations there is no big difference after February 2013 ... rather less risk of getting bug fixes which, by accident, change behavior. Therefore after February 2013 users updating need less validation when updating. All true as well. And as I said, I'm not really gunning for full support to be extended (beyond 5.5.0 final, anyway). I think the idea of being flexible on this is fine so long as there's an eventual hard and fast date announced some time next year. Let's see how the distro situation shakes out, and how the charm offensive in the first half of next year goes in terms of getting users to upgrade to 5.4 and 5.5. :) I just wanted to flag it, mostly. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 - end of live schedule
hi Johannes, On Mon, Dec 10, 2012 at 11:58 AM, Johannes Schlüter johan...@php.net wrote: Hi, after 5.4.0 was released we had a discussion on 5.3 EOL. Even though it wasn't properly documented the overall consensus was to go with option one from https://wiki.php.net/rfc/php53eol One year with bugs fixes followed by one year with security fixes only There was no consensus, I am not sure where you get the idea. However, we discussed to wait a bit before proposing the RFC to clearly and cleanly define the EOL of 5.3. I will clean up this RFC and call for vote later this week (most likely tomorrow). It is very important to follow this step instead of simply say, hey, I will go down this way because I like it ;-) So as quick reminder and help for the ones who don't want to do the maths about our current release schedule themselves the schedule looks like this: December 20th -- Release PHP 5.3.20 January 2nd -- Branch of PHP 5.3.21 January 17th -- Release PHP 5.3.21 January 30th -- Branch of PHP 5.3.22 February 14th -- Release PHP 5.3.22 As of this date the 5.3 branch will go to extended support and should receive security fixes only. Releases will be made based on need. Please mind that the above schedule is tentative and unpredictable events might change this. Comments? The delay is way too short for 3rd parties to adapt. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 - end of live schedule
On Mon, 2012-12-10 at 21:08 +0800, Adam Harvey wrote: To be honest, Debian isn't really the distribution I'm worried about. Ondřej does good work, and Debian Wheezy has PHP 5.4 and isn't miles off, it seems. RHEL and Ubuntu are mostly the ones I'm thinking of here — RHEL 7 is supposed to be out in the second half of next year, but history (and my own experience both in supporting users and dealing with vendors) suggests that RHEL users are slow to upgrade. Ubuntu won't have another LTS release until 2014. All those are interested in are critical/security fixes. Besides that the version is frozen. So for those I don't see a benefit to continue providing unrelated fixes. Please also mind: Most bugs exist for years, most are older than 5.3. If they lived with those on 5.2 they are no stoppers to migrate away from there. The biggest category of 5.3-only bugs is around gc. PHP 5.3 won't stop working and for operations there is no big difference after February 2013 ... rather less risk of getting bug fixes which, by accident, change behavior. Therefore after February 2013 users updating need less validation when updating. All true as well. And as I said, I'm not really gunning for full support to be extended (beyond 5.5.0 final, anyway). I think the idea of being flexible on this is fine so long as there's an eventual hard and fast date announced some time next year. Let's see how the distro situation shakes out, and how the charm offensive in the first half of next year goes in terms of getting users to upgrade to 5.4 and 5.5. :) I just wanted to flag it, mostly. ... and getting this discussion is why I sent the mail out. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 - end of live schedule
Hi, On Mon, 2012-12-10 at 14:10 +0100, Pierre Joye wrote: There was no consensus, I am not sure where you get the idea. By spending the time to go through the thread, taking the opinions stated there, filtering out side discussions (like LTS based release models etc) evaluating it (partly subjective) and summarizing it as in the mail starting this thread. However, we discussed to wait a bit before proposing the RFC to clearly and cleanly define the EOL of 5.3. Your message saying 5.4 was released on March, 1st. That's why I asked this question now while it should have been done before. which is one of the last from the thread doesnt' sound like delaying for additional 3/4 years for a decision. I will clean up this RFC and call for vote later this week (most likely tomorrow). It is very important to follow this step instead of simply say, hey, I will go down this way because I like it ;-) feel free to do what you want. The delay is way too short for 3rd parties to adapt. If people can provide reasons to extend it I'm open to hear those. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 - end of live schedule
On 10.12.2012 15:24, Johannes Schlüter wrote: On Mon, 2012-12-10 at 21:08 +0800, Adam Harvey wrote: To be honest, Debian isn't really the distribution I'm worried about. Ondřej does good work, and Debian Wheezy has PHP 5.4 and isn't miles off, it seems. RHEL and Ubuntu are mostly the ones I'm thinking of here — RHEL 7 is supposed to be out in the second half of next year, but history (and my own experience both in supporting users and dealing with vendors) suggests that RHEL users are slow to upgrade. Ubuntu won't have another LTS release until 2014. All those are interested in are critical/security fixes. Besides that the version is frozen. So for those I don't see a benefit to continue providing unrelated fixes. Yes, with RHEL 6.3 using 5.3.3 I don't see how doing anything besides going into bugfix mode is going to benefit those users, or is there a 6.4 planned? Greetings, Florian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 - end of live schedule
Has APC's PHP 5.4.x support matured yet to the point where folks are comfortable there's no environment in which you really shouldn't run 5.3? On Mon, Dec 10, 2012 at 3:10 PM, Florian Anderiasch flor...@anderiasch.de wrote: On 10.12.2012 15:24, Johannes Schlüter wrote: On Mon, 2012-12-10 at 21:08 +0800, Adam Harvey wrote: To be honest, Debian isn't really the distribution I'm worried about. Ondřej does good work, and Debian Wheezy has PHP 5.4 and isn't miles off, it seems. RHEL and Ubuntu are mostly the ones I'm thinking of here — RHEL 7 is supposed to be out in the second half of next year, but history (and my own experience both in supporting users and dealing with vendors) suggests that RHEL users are slow to upgrade. Ubuntu won't have another LTS release until 2014. All those are interested in are critical/security fixes. Besides that the version is frozen. So for those I don't see a benefit to continue providing unrelated fixes. Yes, with RHEL 6.3 using 5.3.3 I don't see how doing anything besides going into bugfix mode is going to benefit those users, or is there a 6.4 planned? Greetings, Florian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 - end of live schedule
(Really shouldn't run 5.4, rather) On Mon, Dec 10, 2012 at 3:52 PM, Tom Boutell t...@punkave.com wrote: Has APC's PHP 5.4.x support matured yet to the point where folks are comfortable there's no environment in which you really shouldn't run 5.3? On Mon, Dec 10, 2012 at 3:10 PM, Florian Anderiasch flor...@anderiasch.de wrote: On 10.12.2012 15:24, Johannes Schlüter wrote: On Mon, 2012-12-10 at 21:08 +0800, Adam Harvey wrote: To be honest, Debian isn't really the distribution I'm worried about. Ondřej does good work, and Debian Wheezy has PHP 5.4 and isn't miles off, it seems. RHEL and Ubuntu are mostly the ones I'm thinking of here — RHEL 7 is supposed to be out in the second half of next year, but history (and my own experience both in supporting users and dealing with vendors) suggests that RHEL users are slow to upgrade. Ubuntu won't have another LTS release until 2014. All those are interested in are critical/security fixes. Besides that the version is frozen. So for those I don't see a benefit to continue providing unrelated fixes. Yes, with RHEL 6.3 using 5.3.3 I don't see how doing anything besides going into bugfix mode is going to benefit those users, or is there a 6.4 planned? Greetings, Florian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 - end of live schedule
hi, On Mon, Dec 10, 2012 at 9:52 PM, Tom Boutell t...@punkave.com wrote: Has APC's PHP 5.4.x support matured yet to the point where folks are comfortable there's no environment in which you really shouldn't run 5.3? For most apps it should work fine now. There are one or two issues in some edge cases but we see less and less reports about it. But good testing with your apps should be a must do before going wild :) -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 - end of live schedule
Sure. I wasn't asking for myself but rather in the context of how close 5.3 is to being reasonable to deprecate. On Mon, Dec 10, 2012 at 3:55 PM, Pierre Joye pierre@gmail.com wrote: hi, On Mon, Dec 10, 2012 at 9:52 PM, Tom Boutell t...@punkave.com wrote: Has APC's PHP 5.4.x support matured yet to the point where folks are comfortable there's no environment in which you really shouldn't run 5.3? For most apps it should work fine now. There are one or two issues in some edge cases but we see less and less reports about it. But good testing with your apps should be a must do before going wild :) -- Pierre @pierrejoye -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 - end of live schedule
On 12/10/2012 12:59 PM, Tom Boutell wrote: Sure. I wasn't asking for myself but rather in the context of how close 5.3 is to being reasonable to deprecate. APC is at the point now for 5.4 where I don't think there are any more edge cases than we have in 5.3. Neither is perfect, but it is close enough for the majority of sites. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 - end of live schedule
2012/12/10 Adam Harvey ahar...@php.net: On 10 December 2012 18:58, Johannes Schlüter johan...@php.net wrote: As of this date the 5.3 branch will go to extended support and should receive security fixes only. Releases will be made based on need. Please mind that the above schedule is tentative and unpredictable events might change this. Comments? I think there is no consensus of EOL of 5.3 from last discussion as Pierre mentioned. At the very least, I think we should keep full support going until 5.5.0 final is out, which it strikes me probably won't be in February at our current rate. Anyway, I'm +1 for extending 5.3 EOL at least until 5.5.0 release. How about announce 5.3 EOL in 5.5 RC release notes? -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 - end of live schedule
On Tue, 2012-12-11 at 08:55 +0900, Yasuo Ohgaki wrote: 2012/12/10 Adam Harvey ahar...@php.net: On 10 December 2012 18:58, Johannes Schlüter johan...@php.net wrote: As of this date the 5.3 branch will go to extended support and should receive security fixes only. Releases will be made based on need. Please mind that the above schedule is tentative and unpredictable events might change this. Comments? I think there is no consensus of EOL of 5.3 from last discussion as Pierre mentioned. In the thread [RFC] discussions, about a 5.3 EOL mostly supported option #1 from the RFC, some were convinced and changed their opinion for #1, one wished for some LTS kind of model (which is an independent thing which means replacing the current release model, aka nowadays relevant for 5.5) Some people commented about waiting for 5.5 but not as much. Also the proposer of that RFC mentioned this had to be decided now depending on 5.4's release, but apparently didn't see need to formalize this by a vote which I also interpreted(!) as part of a consensus. At the very least, I think we should keep full support going until 5.5.0 final is out, which it strikes me probably won't be in February at our current rate. Anyway, I'm +1 for extending 5.3 EOL at least until 5.5.0 release. Well, people don't trust .0 versions, so we then should wait for 5.5.1 or 5.5.2 ... but by then 5.6 will already be in development, so why not wait for 5.6? But more seriously: 5.3 won't stop working and will still receive critical fixes for at least a year. Users will also face less risk while updating that a fix broke something by accident. As a recent example take a look at commit 6dff07 (Fixed bug #63512 parse_ini_file() with INI_SCANNER_RAW removes quotes from value). This change slightly changes the behavior. People might treat the current behavior, which was introduced while fixing #51094 for 5.3.15 as feature even though (I assume) most users would see #51094 and #63512, as clear bugs. Such changes force people to verify each and every release. If we limit ourselves to critical issues we a) reduce the risk of adding new bugs (like #63512) b) make the verification process for users simpler as less things in the code change. While, yes, there might be a few more bugs, but they are at least documented in the bug tracker and fixes and different work-arounds exist. (and if too many people stumble over it, it can still be escalated and become critical) A bit related rant: Looking at the commit times of some merges it seems unlikely that all changes are actually tested in all branches. When there is less than two minutes between a commit to 5.3 and merge to 5.4, 5.5 and master I assume that often the only test is about merge conflicts -- not even a compile test. Of course people might do some manual things outside git, do merges with --no-commit first and later commit or do some rewrite in between ... but I assume the less branches we have the higher the percentage of tested branches is (pessimistically: from 25% to 33.3%) How about announce 5.3 EOL in 5.5 RC release notes? RCs don't reach the same audience. PHP 5.3.x release notes need it. 5.5.0-final release notes will certainly receive our boilerplate All users are suggested to update snippet, maybe a bit extended. Which is also why I hope we reach an agreement before release 5.3.20 on Thursday next week. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
