Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] PHP 5.7 »

[RFC] PHP 5.7

php.internals

Andrew Faulds

11 years ago
Good evening, There has been some debate about whether to make “PHP 5.7". I have made a very simple RFC. It proposes a final minor version of PHP 5, PHP 5.7, to be released at the same time as PHP 7, with no new features whatsoever. The hope is that we can put this to a vote in 2 weeks’ time and settle the matter, just as we did with the PHP 6/7 name vote, although perhaps slightly less messily this time. ;) The RFC can be found here: https://wiki.php.net/rfc/php57 Thanks!
-- Andrea Faulds http://ajf.me/

Adam Harvey

11 years ago
On 15 December 2014 at 16:09, Andrea Faulds <ajf@ajf.me> wrote:
> The RFC can be found here: https://wiki.php.net/rfc/php57
Thanks for the taking the initiative on this. On timing: I think we should release 5.7 in August (12 months after 5.6), rather than lining it up with 7.0. This gives us the opportunity to then focus our attention on 7.0 entirely for the crucial RC phase of that release. Given the limited scope of 5.7, we shouldn't need as long a testing cycle. Adam

Andrew Faulds

11 years ago
Hi Adam,
> On 16 Dec 2014, at 00:15, Adam Harvey <aharvey@php.net> wrote: > > On 15 December 2014 at 16:09, Andrea Faulds <ajf@ajf.me> wrote: >> The RFC can be found here: https://wiki.php.net/rfc/php57 > > Thanks for the taking the initiative on this. > > On timing: I think we should release 5.7 in August (12 months after > 5.6), rather than lining it up with 7.0. This gives us the opportunity > to then focus our attention on 7.0 entirely for the crucial RC phase > of that release. Given the limited scope of 5.7, we shouldn't need as > long a testing cycle.
That’s a good point, it doesn’t actually have to line up with 7’s release and focus on 7.0 RC is crucial given the major changes. If others think this is a good idea, I’ll amend the RFC. Thanks!
-- Andrea Faulds http://ajf.me/

Kris Craig

11 years ago
On Mon, Dec 15, 2014 at 4:20 PM, Andrea Faulds <ajf@ajf.me> wrote:
> Hi Adam, > > > On 16 Dec 2014, at 00:15, Adam Harvey <aharvey@php.net> wrote: > > > > On 15 December 2014 at 16:09, Andrea Faulds <ajf@ajf.me> wrote: > >> The RFC can be found here: https://wiki.php.net/rfc/php57 > > > > Thanks for the taking the initiative on this. > > > > On timing: I think we should release 5.7 in August (12 months after > > 5.6), rather than lining it up with 7.0. This gives us the opportunity > > to then focus our attention on 7.0 entirely for the crucial RC phase > > of that release. Given the limited scope of 5.7, we shouldn't need as > > long a testing cycle. > > That’s a good point, it doesn’t actually have to line up with 7’s release > and focus on 7.0 RC is crucial given the major changes. > > If others think this is a good idea, I’ll amend the RFC. > > Thanks! > -- > Andrea Faulds > http://ajf.me/ > > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
+1 on this. I agree with Adam; it'd be better to line up 5.7 with the support timeline for 5.6 and just handle 7's timeline separately. --Kris

Andrew Faulds

11 years ago
Hi everyone,
> On 16 Dec 2014, at 00:15, Adam Harvey <aharvey@php.net> wrote: > > On 15 December 2014 at 16:09, Andrea Faulds <ajf@ajf.me> wrote: >> The RFC can be found here: https://wiki.php.net/rfc/php57 > > Thanks for the taking the initiative on this. > > On timing: I think we should release 5.7 in August (12 months after > 5.6), rather than lining it up with 7.0. This gives us the opportunity > to then focus our attention on 7.0 entirely for the crucial RC phase > of that release. Given the limited scope of 5.7, we shouldn't need as > long a testing cycle.
> On 16 Dec 2014, at 01:19, Kris Craig <kris.craig@gmail.com> wrote: > > +1 on this. I agree with Adam; it'd be better to line up 5.7 with the support timeline for 5.6 and just handle 7's timeline separately. >
I’ve updated the RFC to target August 2015 for release. This would mean it would come out a year after 5.6, and the RC phase would be half as PHP 7’s.
> On 16 Dec 2014, at 05:51, Andrea Faulds <ajf@ajf.me> wrote: > > Also, I failed to mention it in the RFC (will do so), but for any new reserved words in PHP 7, we should also reserve them in 5.7.
I’ve also updated the to note that reserved words in PHP 7 can be pre-reserved in PHP 5.7. Thanks for your comments!
-- Andrea Faulds http://ajf.me/

Laruence

11 years ago
On Tue, Dec 16, 2014 at 8:09 AM, Andrea Faulds <ajf@ajf.me> wrote:
> Good evening, > > There has been some debate about whether to make “PHP 5.7". I have made a very simple RFC. It proposes a final minor version of PHP 5, PHP 5.7, to be released at the same time as PHP 7, with no new features whatsoever. >
I am wondering why we need that? no new features.... I think we can extend 5.6 release cycle to avoid that.. thanks
> The hope is that we can put this to a vote in 2 weeks’ time and settle the matter, just as we did with the PHP 6/7 name vote, although perhaps slightly less messily this time. ;) > > The RFC can be found here: https://wiki.php.net/rfc/php57 > > Thanks! > -- > Andrea Faulds > http://ajf.me/ > > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
-- Xinchen Hui @Laruence http://www.laruence.com/

Andrew Faulds

11 years ago
Hi Xinchen,
> On 16 Dec 2014, at 04:07, Xinchen Hui <laruence@php.net> wrote: > > On Tue, Dec 16, 2014 at 8:09 AM, Andrea Faulds <ajf@ajf.me> wrote: >> Good evening, >> >> There has been some debate about whether to make “PHP 5.7". I have made a very simple RFC. It proposes a final minor version of PHP 5, PHP 5.7, to be released at the same time as PHP 7, with no new features whatsoever. >> > I am wondering why we need that? no new features….
The reasoning behind this is to encourage people to switch to PHP 7 if they want new features.
> I think we can extend 5.6 release cycle to avoid that..
We could, but we wouldn’t be able to introduce deprecation notices in a 5.6 micro, so we’d need a new minor releases. Also, I failed to mention it in the RFC (will do so), but for any new reserved words in PHP 7, we should also reserve them in 5.7. Thanks.
-- Andrea Faulds http://ajf.me/

Levi Morrison

11 years ago
>> There has been some debate about whether to make “PHP 5.7". I have made a very simple RFC. It proposes a final minor version of PHP 5, PHP 5.7, to be released at the same time as PHP 7, with no new features whatsoever. >> > I am wondering why we need that? no new features.... > > I think we can extend 5.6 release cycle to avoid that..
Extending the PHP 5.6 release cycle doesn't give an opportunity to raise different E_STRICT and E_DEPRECATED messages in preparation for PHP 7.0. This may or may not be something you value, but it's something I personally value.

Lester Caine

11 years ago
On 16/12/14 07:29, Levi Morrison wrote:
>>> There has been some debate about whether to make “PHP 5.7". I have made a very simple RFC. It proposes a final minor version of PHP 5, PHP 5.7, to be released at the same time as PHP 7, with no new features whatsoever. >>> >> >> > I am wondering why we need that? no new features.... >> > >> > I think we can extend 5.6 release cycle to avoid that.. > Extending the PHP 5.6 release cycle doesn't give an opportunity to > raise different E_STRICT and E_DEPRECATED messages in preparation for > PHP 7.0. This may or may not be something you value, but it's > something I personally value.
+1 Leave 5.6 as a 'clean' version so stability is retained. 5.7 is an optional stepping stone to help upgrade code, but for users of frameworks will have their content migrated from an older platform to a clean PHP7 one. It is only those users who have personal code that need help migrating. 5.7 would have sub versions as particular problems are identified in the migration process rather than encumbering PHP7 with unnecessary bloat?
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Zeev Suraski

11 years ago
> -----Original Message----- > From: morrison.levi@gmail.com [mailto:morrison.levi@gmail.com] On > Behalf Of Levi Morrison > Sent: Tuesday, December 16, 2014 9:29 AM > To: Xinchen Hui > Cc: Andrea Faulds; PHP Internals > Subject: Re: [PHP-DEV] [RFC] PHP 5.7 > > >> There has been some debate about whether to make “PHP 5.7". I have > made a very simple RFC. It proposes a final minor version of PHP 5, PHP > 5.7, > to be released at the same time as PHP 7, with no new features whatsoever. > >> > > I am wondering why we need that? no new features.... > > > > I think we can extend 5.6 release cycle to avoid that.. > > Extending the PHP 5.6 release cycle doesn't give an opportunity to raise > different E_STRICT and E_DEPRECATED messages in preparation for PHP 7.0. > This may or may not be something you value, but it's something I > personally > value.
I don't see why we'd need new E_STRICT's, but what stops us from adding E_DEPRECATED to 5.6.x? I think the likelihood of getting these notices in the hands of people goes way higher if we put it into 5.6.x, which will be perceived as a bug-fix release, than a 5.7.0, which will be perceived as a feature release. Zeev

Ferenc Kovacs

11 years ago
On Tue, Dec 16, 2014 at 4:23 PM, Zeev Suraski <zeev@zend.com> wrote:
> > > -----Original Message----- > > From: morrison.levi@gmail.com [mailto:morrison.levi@gmail.com] On > > Behalf Of Levi Morrison > > Sent: Tuesday, December 16, 2014 9:29 AM > > To: Xinchen Hui > > Cc: Andrea Faulds; PHP Internals > > Subject: Re: [PHP-DEV] [RFC] PHP 5.7 > > > > >> There has been some debate about whether to make “PHP 5.7". I have > > made a very simple RFC. It proposes a final minor version of PHP 5, PHP > > 5.7, > > to be released at the same time as PHP 7, with no new features > whatsoever. > > >> > > > I am wondering why we need that? no new features.... > > > > > > I think we can extend 5.6 release cycle to avoid that.. > > > > Extending the PHP 5.6 release cycle doesn't give an opportunity to raise > > different E_STRICT and E_DEPRECATED messages in preparation for PHP 7.0. > > This may or may not be something you value, but it's something I > > personally > > value. > > I don't see why we'd need new E_STRICT's, but what stops us from adding > E_DEPRECATED to 5.6.x? > > I think the likelihood of getting these notices in the hands of people goes > way higher if we put it into 5.6.x, which will be perceived as a bug-fix > release, than a 5.7.0, which will be perceived as a feature release. > >
as you mentioned distros lock in to a specific micro version, so if we introduce this deprecated messages in random micro version, we make it less likely for the users to stumble upon those deprecated messages and it will be also harder for us to communicate the upgrade path: compare: okay, you only have to install PHP 5.7 check out the deprecated messages in your error logs, fix those and you are ready to upgrade to 7.0 vs okay, so install 5.6, but make sure that it is >= 5.6.x, except for distro Z, because they bumped the version but only backported the security fixes but did not include the last deprecated message and if you fixed those deprecated messages from your error log, you are ready to upgrade to 7.0.
-- Ferenc Kovács @Tyr43l - http://tyrael.hu

Zeev Suraski

11 years ago
as you mentioned distros lock in to a specific micro version, so if we introduce this deprecated messages in random micro version, we make it less likely for the users to stumble upon those deprecated messages and it will be also harder for us to communicate the upgrade path: compare: okay, you only have to install PHP 5.7 check out the deprecated messages in your error logs, fix those and you are ready to upgrade to 7.0 vs okay, so install 5.6, but make sure that it is >= 5.6.x, except for distro Z, because they bumped the version but only backported the security fixes but did not include the last deprecated message and if you fixed those deprecated messages from your error log, you are ready to upgrade to 7.0. [Zeev] Distros don’t bump the version number when they backport patches from newer versions. It stays the same, which is why I don’t think there’s any difference between the two as far as communications is concerned. It’s really ‘Upgrade to 5.7’ vs. ‘Upgrade to 5.6.12 or later’ – both messages by the way irrelevant to distro users (which have little or no control over the version of PHP they’re using, unless they break away from the standard distro PHP). The people we really talk about are the people they build their own or otherwise obtain non-standard-distro binaries. For them, I do believe a jump to 5.7.x will be psychologically bigger than a hop to a newer 5.6.x version.

Ferenc Kovacs

11 years ago
On Tue, Dec 16, 2014 at 5:44 PM, Zeev Suraski <zeev@zend.com> wrote:
> > as you mentioned distros lock in to a specific micro version, so if we > introduce this deprecated messages in random micro version, we make it less > likely for the users to stumble upon those deprecated messages and it will > be also harder for us to communicate the upgrade path: > > compare: > > okay, you only have to install PHP 5.7 check out the deprecated messages > in your error logs, fix those and you are ready to upgrade to 7.0 > > vs > > okay, so install 5.6, but make sure that it is >= 5.6.x, except for distro > Z, because they bumped the version but only backported the security fixes > but did not include the last deprecated message and if you fixed those > deprecated messages from your error log, you are ready to upgrade to 7.0. > > > > [Zeev] Distros don’t bump the version number when they backport patches > from newer versions. It stays the same, which is why I don’t think there’s > any difference between the two as far as communications is concerned. It’s > really ‘Upgrade to 5.7’ vs. ‘Upgrade to 5.6.12 or later’ – both messages by > the way irrelevant to distro users (which have little or no control over > the version of PHP they’re using, unless they break away from the standard > distro PHP). The people we really talk about are the people they build > their own or otherwise obtain non-standard-distro binaries. For them, I do > believe a jump to 5.7.x will be psychologically bigger than a hop to a > newer 5.6.x version. > > >
my point was that it is easier to say that you can use whatever 5.7 release to make sure you are fine to upgrade to 7.0 versus depending on a specific 5.6 micro version. but you are right that most distros don't bump the upstream version but suffix it with their own revision number, and bump that when backporting bug/security fixes.
-- Ferenc Kovács @Tyr43l - http://tyrael.hu

Rowan Collins

11 years ago
On 16 December 2014 16:44:59 GMT, Zeev Suraski <zeev@zend.com> wrote:
>as you mentioned distros lock in to a specific micro version, so if we >introduce this deprecated messages in random micro version, we make it >less >likely for the users to stumble upon those deprecated messages and it >will >be also harder for us to communicate the upgrade path: > >compare: > >okay, you only have to install PHP 5.7 check out the deprecated >messages in >your error logs, fix those and you are ready to upgrade to 7.0 > >vs > >okay, so install 5.6, but make sure that it is >= 5.6.x, except for >distro >Z, because they bumped the version but only backported the security >fixes >but did not include the last deprecated message and if you fixed those >deprecated messages from your error log, you are ready to upgrade to >7.0. > > > >[Zeev] Distros don’t bump the version number when they backport patches >from newer versions. It stays the same, which is why I don’t think >there’s >any difference between the two as far as communications is concerned. >It’s >really ‘Upgrade to 5.7’ vs. ‘Upgrade to 5.6.12 or later’ – both >messages by >the way irrelevant to distro users (which have little or no control >over >the version of PHP they’re using, unless they break away from the >standard >distro PHP). The people we really talk about are the people they build >their own or otherwise obtain non-standard-distro binaries. For them, >I do >believe a jump to 5.7.x will be psychologically bigger than a hop to a >newer 5.6.x version.
If people stick with their distribution's cycle, then this is true. However, many distributions these days have active "backport" eco systems. You're unlikely to find, say, an Ubuntu PPA offering 5.6.12 to replace 5.6.3, but you're almost certain to find one porting 5.7.0 to that same distro release. I don't know for sure that more conservative distros like Red Hat would be similar, but it seems more likely than not that "upgrade to 5.7" would be easier advice to follow than "upgrade to 5.6.12". Regards,
-- Rowan Collins [IMSoP]

Florian Margaine

11 years ago
Hi list, I think having a minor PHP version for the only sake of adding E_DEPRECATED is kind of pointless to be honest. Historically, PHP (or other languages for the matter, I'm thinking of python) minor versions have brought new features. Adding notices is not a reason for a new version imho. If what we want are notices, and helping people to migrate to PHP 7, then we can create tools for this. For example, python made a tool to help with the transition of python 2 to python 3. Go did the same for 0.x to 1.0, if my memory serves right. The point of new versions is to include new features or bug fixes for the language, static analysis can be done with external tools. The fact that we'll have to maintain one more version is also not something to be taken lightly, especially when I see examples of how things progress in php-src. (I'm thinking about the recent contributor who gave up.) Now, if the reason people want PHP 5.7 is to extend PHP 5 lifetime, then it's another matter, and the lifetime of existing versions could be extended. Just my $0.02. Cheers, Florian Margaine

Julien Pauli

11 years ago
On Tue, Dec 16, 2014 at 8:55 PM, Florian Margaine <florian@margaine.com> wrote:
> > Hi list, > > I think having a minor PHP version for the only sake of adding E_DEPRECATED > is kind of pointless to be honest. Historically, PHP (or other languages > for the matter, I'm thinking of python) minor versions have brought new > features. Adding notices is not a reason for a new version imho. > > If what we want are notices, and helping people to migrate to PHP 7, then > we can create tools for this. For example, python made a tool to help with > the transition of python 2 to python 3. Go did the same for 0.x to 1.0, if > my memory serves right. The point of new versions is to include new > features or bug fixes for the language, static analysis can be done with > external tools. > > The fact that we'll have to maintain one more version is also not something > to be taken lightly, especially when I see examples of how things progress > in php-src. (I'm thinking about the recent contributor who gave up.) > > Now, if the reason people want PHP 5.7 is to extend PHP 5 lifetime, then > it's another matter, and the lifetime of existing versions could be > extended. > > Just my $0.02. > >
That's a perfectly valid POV I share. So I sum-up and introduce the dilema : - We should push people to PHP7 , whatever the way - We cannot patch 5.6 to add any Warnings-of-any-kind (stable release, under release process that forbids that) - Rolling out a 5.7 with *just* Warnings-of-any-kind is silly, see the topic I just replied to which is valid to me - Rolling out a 5.7 with Warnings-of-any-kind + some little-or-not new features cancels point number one What else ? Julien.Pauli

Zeev Suraski

11 years ago
> -----Original Message----- > From: julienpauli@gmail.com [mailto:julienpauli@gmail.com] On Behalf Of > Julien Pauli > Sent: Tuesday, December 16, 2014 11:00 PM > To: Florian Margaine > Cc: Rowan Collins; PHP Internals > Subject: Re: [PHP-DEV] [RFC] PHP 5.7 > > - We cannot patch 5.6 to add any Warnings-of-any-kind (stable release, > under release process that forbids that)
What part of the release process forbids that? I don't see that anywhere in there, at least not any more than it forbids such deprecation messages in a minor (2nd digit) version. New features are the only (relevant) difference between minor and bugfix versions, and I don't think anybody considers deprecation messages as new features. They are, in practice, very minor compatibility breakages - and in that sense, technically, both bugfix (3rd digit) and minor (2nd digit) versions forbid those equally. Also note that the release process isn't exactly a flawless document that predicted all the scenarios we're facing (and are going to face) in the future. Its focus was bugfix and minor releases, and consequently, not much thought was made regarding migration issues of the sorts we're discussing today, towards a major version. If we reach the conclusion (and it's clearly an if), it's not the release process that should stop us.
> - Rolling out a 5.7 with *just* Warnings-of-any-kind is silly, see the > topic I > just replied to which is valid to me
Agreed.
> - Rolling out a 5.7 with Warnings-of-any-kind + some little-or-not new > features cancels point number one > > What else ?
Do nothing is still (IMHO) the most sensible option IMHO. We're not seeing major compatibility breakages in 7.0 (at least not at this time), to the level that upgrading through some middle version is really all that necessary. Considering the adoption levels of 5.6, 5.5 and even 5.4, we can expect that most people migrating to PHP 7 will not be doing it from one of the latest PHP 5.x versions, but older ones, rendering all of these options useless. The one option that could be relevant to these scenarios is a separate analysis tool, but it's much more difficult to pull off, and I don't think the level of breakage (as it appears right now) justifies the effort. Zeev

Ferenc Kovacs

11 years ago
On Tue, Dec 16, 2014 at 9:59 PM, Julien Pauli <jpauli@php.net> wrote:
> > On Tue, Dec 16, 2014 at 8:55 PM, Florian Margaine <florian@margaine.com> > wrote: > > > > Hi list, > > > > I think having a minor PHP version for the only sake of adding > E_DEPRECATED > > is kind of pointless to be honest. Historically, PHP (or other languages > > for the matter, I'm thinking of python) minor versions have brought new > > features. Adding notices is not a reason for a new version imho. > > > > If what we want are notices, and helping people to migrate to PHP 7, then > > we can create tools for this. For example, python made a tool to help > with > > the transition of python 2 to python 3. Go did the same for 0.x to 1.0, > if > > my memory serves right. The point of new versions is to include new > > features or bug fixes for the language, static analysis can be done with > > external tools. > > > > The fact that we'll have to maintain one more version is also not > something > > to be taken lightly, especially when I see examples of how things > progress > > in php-src. (I'm thinking about the recent contributor who gave up.) > > > > Now, if the reason people want PHP 5.7 is to extend PHP 5 lifetime, then > > it's another matter, and the lifetime of existing versions could be > > extended. > > > > Just my $0.02. > > > > > That's a perfectly valid POV I share. > > So I sum-up and introduce the dilema : > > - We should push people to PHP7 , whatever the way >
I don't think we can really "push" people to migrate, instead of that we can make the migration as painless and possible, and hope that distros and app/lib developers will pull the ecosystem with them (for example an initiative like gophp5 would not have happened if we were trying to organize and push that or devs did not thought that php5 is superior to php4, same thing here).
> - We cannot patch 5.6 to add any Warnings-of-any-kind (stable release, > under release process that forbids that) >
even thought that Pierre stated this in a previous mail, but AFAIK there is no such rule(https://wiki.php.net/rfc/releaseprocess) and we have a couple of precedences, but I do agree that it would be a bad idea to add a bunch of new errors in a micro version, as there are people out there who run code in production with enabled display_errors and have E_DEPRECATED in error_reporting: https://bugs.php.net/bug.php?id=66763
> - Rolling out a 5.7 with *just* Warnings-of-any-kind is silly, see the > topic I just replied to which is valid to me >
I think that some people in this thread would still vote yes for such a version, but I think that small additions like the last couple of function addition in 5.6.x would be ok.
> - Rolling out a 5.7 with Warnings-of-any-kind + some little-or-not new > features cancels point number one >
I wouldn't say it cancels it, I mean I agree that not having any new feature (even the smallest one) in 5.x will have a positive effect on the number of people upgrading, but I don't think that php7 will fail because we added gmp_random_range() in 5.6.3.
> > What else ? >
I think that the core difference between the people on the two sides are how they view the gains from the easier upgrading between 5.7->7.0 versus the cost of release/maintenance of another minor and how would that affect the effort put into 7.0. I think that the pros are outweighing the cons, but that's just me. I don't know how could we quantify the first one(gains from easier upgrading), but we can try to do that for the second(future cost of maintenance) and then hold a vote to see what others think.
-- Ferenc Kovács @Tyr43l - http://tyrael.hu

Andrew Faulds

11 years ago
Hey Florian,
> On 16 Dec 2014, at 19:55, Florian Margaine <florian@margaine.com> wrote: > > Hi list, > > I think having a minor PHP version for the only sake of adding E_DEPRECATED > is kind of pointless to be honest. Historically, PHP (or other languages > for the matter, I'm thinking of python) minor versions have brought new > features. Adding notices is not a reason for a new version imho. > > If what we want are notices, and helping people to migrate to PHP 7, then > we can create tools for this. For example, python made a tool to help with > the transition of python 2 to python 3. Go did the same for 0.x to 1.0, if > my memory serves right. The point of new versions is to include new > features or bug fixes for the language, static analysis can be done with > external tools. > > The fact that we'll have to maintain one more version is also not something > to be taken lightly, especially when I see examples of how things progress > in php-src. (I'm thinking about the recent contributor who gave up.) > > Now, if the reason people want PHP 5.7 is to extend PHP 5 lifetime, then > it's another matter, and the lifetime of existing versions could be > extended. > > Just my $0.02. > > Cheers, > Florian Margaine
Hmm, actually, a 2to3-esque tool and a formal extension of 5.6's support by a year sounds like a better solution. If others agree, I might withdraw this RFC. Thanks!
-- Andrea Faulds http://ajf.me/

Adam Harvey

11 years ago
On 16 December 2014 at 13:18, Andrea Faulds <ajf@ajf.me> wrote:
> Hmm, actually, a 2to3-esque tool and a formal extension of 5.6's support by a year sounds like a better solution. If others agree, I might withdraw this RFC.
I disagree. 2to3 wasn't a success in the Python world — in the end, the only migration solution that worked there was code bases that could run on both Python 2 and 3 (with the help of userland compatibility libraries like six and python-future), and I believe the same will be true for PHP 5 and 7. More generally, I don't believe a standalone CLI tool can be the whole answer even if that wasn't a problem: too many of our users only ever run their code in shared Web server environments and aren't proficient enough at the command line (on whatever OS they choose) for that kind of tooling. I'm sure someone will write a 2to3 type tool, and that some people will find it useful, but I don't think it's the right answer in terms of advertising a migration path. Adam

Pierre Joye

11 years ago
On Dec 17, 2014 4:19 AM, "Andrea Faulds" <ajf@ajf.me> wrote:
> > Hey Florian, > > > On 16 Dec 2014, at 19:55, Florian Margaine <florian@margaine.com> wrote: > > > > Hi list, > > > > I think having a minor PHP version for the only sake of adding
E_DEPRECATED
> > is kind of pointless to be honest. Historically, PHP (or other languages > > for the matter, I'm thinking of python) minor versions have brought new > > features. Adding notices is not a reason for a new version imho. > > > > If what we want are notices, and helping people to migrate to PHP 7,
then
> > we can create tools for this. For example, python made a tool to help
with
> > the transition of python 2 to python 3. Go did the same for 0.x to 1.0,
if
> > my memory serves right. The point of new versions is to include new > > features or bug fixes for the language, static analysis can be done with > > external tools. > > > > The fact that we'll have to maintain one more version is also not
something
> > to be taken lightly, especially when I see examples of how things
progress
> > in php-src. (I'm thinking about the recent contributor who gave up.) > > > > Now, if the reason people want PHP 5.7 is to extend PHP 5 lifetime, then > > it's another matter, and the lifetime of existing versions could be > > extended. > > > > Just my $0.02. > > > > Cheers, > > Florian Margaine > > Hmm, actually, a 2to3-esque tool and a formal extension of 5.6's support
by a year sounds like a better solution. If others agree, I might withdraw this RFC.
> > Thanks!
Please do not. It can be updated but discarding a rfc every time you see a slight opposition is not good. Also an extension won't have the same impact and spread than a new php release.

Ferenc Kovacs

11 years ago
On Tue, Dec 16, 2014 at 8:55 PM, Florian Margaine <florian@margaine.com> wrote:
> > Hi list, > > I think having a minor PHP version for the only sake of adding E_DEPRECATED > is kind of pointless to be honest. Historically, PHP (or other languages > for the matter, I'm thinking of python) minor versions have brought new > features. Adding notices is not a reason for a new version imho. >
please be aware the not everybody agrees on the no new features rule, but from as I can tell most people seem to agree that no new major features should be included. in an ideal world those kind of E_DEPRECATED messages would be there already before we break or remove a function so there would be no reason for this discussion. because this isn't a case I think it is reasonable to have a discussion if it would worth to have another minor in the 5.x series to make the upgrading to 7.0 easier. my proposal was to stop adding minor features into 5.6, create an 5.7 where those can go and make sure that any(which is possible/feasible) BC break will be foretold via E_DEPRECATED.
> > If what we want are notices, and helping people to migrate to PHP 7, then > we can create tools for this. For example, python made a tool to help with > the transition of python 2 to python 3. Go did the same for 0.x to 1.0, if > my memory serves right. The point of new versions is to include new > features or bug fixes for the language, static analysis can be done with > external tools. >
This is not the first time this idea came up, and some of the BC incompatible changes in PHP7 already have such tools to spot such usages or fix them automagically.
> > The fact that we'll have to maintain one more version is also not something > to be taken lightly, especially when I see examples of how things progress > in php-src. (I'm thinking about the recent contributor who gave up.) >
I think it would be a bit more work, but not that much: 5.4 would stay in security fix mod until 5.7 is released, 5.5 and 5.6 would be put/kept in bugfix/security fix mode, new features would only target 5.7 and 7.0. Merging would be one step longer (for another year) in worst case scenario (bugfix or security fix) but even that would be less of a PITA if not for NEWS. (About the recent contributor gave up stuff: I think that is more of a problem when the policies/processes are not explicit and/or abused.)
> > Now, if the reason people want PHP 5.7 is to extend PHP 5 lifetime, then > it's another matter, and the lifetime of existing versions could be > extended. >
That's one reason, which doesn't really require us to do anything, as we have plenty of time to realize if we want to/have to prolong the lifecycle of PHP5, and doesn't take much than updating http://php.net/supported-versions.php and bribing the RMs to cover another year with the RM stuff.
-- Ferenc Kovács @Tyr43l - http://tyrael.hu

Zeev Suraski

11 years ago
> -----Original Message----- > From: Ferenc Kovacs [mailto:tyra3l@gmail.com] > Sent: Tuesday, December 16, 2014 11:53 PM > To: Florian Margaine > Cc: Rowan Collins; PHP Internals > Subject: Re: [PHP-DEV] [RFC] PHP 5.7 > > please be aware the not everybody agrees on the no new features rule, but > from as I can tell most people seem to agree that no new major features > should be included.
That's true, but the only person I see actively campaigning for new features (major or otherwise) appears to be you, Ferenc :) It's *clearly* not in the scope of the RFC that Andrea put on the table - that's consistent with the feedbacks of several different people on the list. We'd need a different or heavily amended RFC in order to allow it. For the record, I'm mostly indifferent to the current RFC (somwhat opposing it as detailed in a previous email), but will clearly oppose any RFC that suggests any sort of feature 5.7 release. Most importantly, it will delay the strategic 7.0 release, but also - slow migration down (less reasons to move upwards to 7.0 if you have some of these features in 5.x). Zeev

Levi Morrison

11 years ago
>> >> There has been some debate about whether to make “PHP 5.7". I have >> made a very simple RFC. It proposes a final minor version of PHP 5, PHP >> 5.7, >> to be released at the same time as PHP 7, with no new features whatsoever. >> >> >> > I am wondering why we need that? no new features.... >> > >> > I think we can extend 5.6 release cycle to avoid that.. >> >> Extending the PHP 5.6 release cycle doesn't give an opportunity to raise >> different E_STRICT and E_DEPRECATED messages in preparation for PHP 7.0. >> This may or may not be something you value, but it's something I >> personally >> value. > > I don't see why we'd need new E_STRICT's, but what stops us from adding > E_DEPRECATED to 5.6.x?
Changing which errors and warnings are emitted in a patch release will likely fill up some unsuspecting user's HDD, and for people writing their own error handlers it may also mess them up. I'd much rather see the change happen in a minor version.

Pierre Joye

11 years ago
On Dec 16, 2014 10:23 PM, "Zeev Suraski" <zeev@zend.com> wrote:
> > > -----Original Message----- > > From: morrison.levi@gmail.com [mailto:morrison.levi@gmail.com] On > > Behalf Of Levi Morrison > > Sent: Tuesday, December 16, 2014 9:29 AM > > To: Xinchen Hui > > Cc: Andrea Faulds; PHP Internals > > Subject: Re: [PHP-DEV] [RFC] PHP 5.7 > > > > >> There has been some debate about whether to make “PHP 5.7". I have > > made a very simple RFC. It proposes a final minor version of PHP 5, PHP > > 5.7, > > to be released at the same time as PHP 7, with no new features
whatsoever.
> > >> > > > I am wondering why we need that? no new features.... > > > > > > I think we can extend 5.6 release cycle to avoid that.. > > > > Extending the PHP 5.6 release cycle doesn't give an opportunity to raise > > different E_STRICT and E_DEPRECATED messages in preparation for PHP 7.0. > > This may or may not be something you value, but it's something I > > personally > > value. > > I don't see why we'd need new E_STRICT's, but what stops us from adding > E_DEPRECATED to 5.6.x?
We do not allow them or we try to avoid them by all means.
> I think the likelihood of getting these notices in the hands of people
goes
> way higher if we put it into 5.6.x, which will be perceived as a bug-fix > release, than a 5.7.0, which will be perceived as a feature release.
And what will be the work load difference then? Zero. However it will introduce changes in a patch release that may not be expected as of our RFC. I am totally opposed to this idea.

Matteo Beccati

11 years ago
On 16/12/2014 05:07, Xinchen Hui wrote:
> On Tue, Dec 16, 2014 at 8:09 AM, Andrea Faulds <ajf@ajf.me> wrote: >> Good evening, >> >> There has been some debate about whether to make “PHP 5.7". I have made a very simple RFC. It proposes a final minor version of PHP 5, PHP 5.7, to be released at the same time as PHP 7, with no new features whatsoever. >> > I am wondering why we need that? no new features.... > > I think we can extend 5.6 release cycle to avoid that..
I tend to agree with Xinchen here. A new minor release just to introduce a few deprecation messages? It sounds like a lot of work (it also need to be maintained) for little gain. I think that doesn't also match the plans of other (accepted?) RFCs that were targeted for 5.7. I think I've seen it many times. Cheers
-- Matteo Beccati Development & Consulting - http://www.beccati.com/

Andrew Faulds

11 years ago
Hi Matteo,
> On 16 Dec 2014, at 07:52, Matteo Beccati <php@beccati.com> wrote: > > On 16/12/2014 05:07, Xinchen Hui wrote: >> On Tue, Dec 16, 2014 at 8:09 AM, Andrea Faulds <ajf@ajf.me> wrote: >>> Good evening, >>> >>> There has been some debate about whether to make “PHP 5.7". I have made a very simple RFC. It proposes a final minor version of PHP 5, PHP 5.7, to be released at the same time as PHP 7, with no new features whatsoever. >>> >> I am wondering why we need that? no new features.... >> >> I think we can extend 5.6 release cycle to avoid that.. > > I tend to agree with Xinchen here. A new minor release just to introduce a few deprecation messages? It sounds like a lot of work (it also need to be maintained) for little gain.
There should be very little work necessary. Deprecations are easy, and the changeset from 5.6 should be tiny at best. The only significant extra work is the added year of maintenance for the PHP 5 line.
> I think that doesn't also match the plans of other (accepted?) RFCs that were targeted for 5.7. I think I've seen it many times.
Could you tell me which RFCs targeted 5.7 and didn’t just add deprecation notices? I’m unaware of any. Thanks.
-- Andrea Faulds http://ajf.me/

Matteo Beccati

11 years ago
On 16/12/2014 08:55, Andrea Faulds wrote:
> Could you tell me which RFCs targeted 5.7 and didn’t just add deprecation notices? I’m unaware of any.
I've tried to search the ML for such list of RFCs: https://wiki.php.net/rfc/gc_fn_pointer https://wiki.php.net/rfc/secure_unserialize (also 5.6 if RMs agree) https://wiki.php.net/rfc/closure_apply https://wiki.php.net/rfc/pack_unpack_64bit_formats (targeting 5.6) https://wiki.php.net/rfc/intdiv https://wiki.php.net/rfc/session.user.return-value maybe others too, but I got bored ;) Cheers
-- Matteo Beccati Development & Consulting - http://www.beccati.com/

Andrew Faulds

11 years ago
Hey Matteo,
> On 16 Dec 2014, at 10:52, Matteo Beccati <php@beccati.com> wrote: > > On 16/12/2014 08:55, Andrea Faulds wrote: >> Could you tell me which RFCs targeted 5.7 and didn’t just add deprecation notices? I’m unaware of any. > > I've tried to search the ML for such list of RFCs: > > https://wiki.php.net/rfc/gc_fn_pointer > https://wiki.php.net/rfc/secure_unserialize (also 5.6 if RMs agree) > https://wiki.php.net/rfc/closure_apply > https://wiki.php.net/rfc/pack_unpack_64bit_formats (targeting 5.6) > https://wiki.php.net/rfc/intdiv > https://wiki.php.net/rfc/session.user.return-value > > maybe others too, but I got bored ;)
I wrote the Closure::call() and intdiv() RFCs. Truth be told, they both targeted master, not a specific PHP version. master has become PHP 7, so whatever the wording of them said, they really target PHP 7 now. They were written back before the whole PHP 7/phpng thing when I didn’t know whether we were going to go straight to PHP 7 or whether there’d be another minor and then PHP 7 a year or two after. Now we’re going straight to PHP 7 - the 5.7 proposed wouldn’t be an exception to that, as 5.7 would have no new features and be released around the same time. It’s not, well, the 5.7 I had in mind when I wrote those RFCs. Filtered unserialize() and 64-bit pack/unpack targeted 5.6 micro releases, not 5.7. I don’t really know about the session handling and GC ones.
-- Andrea Faulds http://ajf.me/

Matteo Beccati

11 years ago
On 16/12/2014 12:03, Andrea Faulds wrote:
> I wrote the Closure::call() and intdiv() RFCs. Truth be told, they > both targeted master, not a specific PHP version. master has become > PHP 7, so whatever the wording of them said, they really target PHP 7 > now. They were written back before the whole PHP 7/phpng thing when I > didn’t know whether we were going to go straight to PHP 7 or whether > there’d be another minor and then PHP 7 a year or two after. Now > we’re going straight to PHP 7 - the 5.7 proposed wouldn’t be an > exception to that, as 5.7 would have no new features and be released > around the same time. It’s not, well, the 5.7 I had in mind when I > wrote those RFCs.
This is what I meant when I previously mentioned seeing RFCs targeting 5.7. I understand what you say and I do wholeheartedly agree with you. However if one would have to strictly follow what has been voted, such features should be backported to whatever becomes 5.7, if any. Perhaps the 5.7 RFC could explicitly states what is (not) going to happen wrt those RFCs.
> I don’t really know about the session handling and GC ones
Likewise. And there might be more that I haven't looked up. Cheers
-- Matteo Beccati Development & Consulting - http://www.beccati.com/

Andrew Faulds

11 years ago
Hey Matteo,
> On 16 Dec 2014, at 11:29, Matteo Beccati <php@beccati.com> wrote: > > This is what I meant when I previously mentioned seeing RFCs targeting 5.7. I understand what you say and I do wholeheartedly agree with you. > > However if one would have to strictly follow what has been voted, such features should be backported to whatever becomes 5.7, if any. Perhaps the 5.7 RFC could explicitly states what is (not) going to happen wrt those RFCs.
I think it’s pretty clear in stating 5.7 will have no new features. Thanks,
-- Andrea Faulds http://ajf.me/

Ferenc Kovacs

11 years ago
On Tue, Dec 16, 2014 at 12:33 PM, Andrea Faulds <ajf@ajf.me> wrote:
> > Hey Matteo, > > > On 16 Dec 2014, at 11:29, Matteo Beccati <php@beccati.com> wrote: > > > > This is what I meant when I previously mentioned seeing RFCs targeting > 5.7. I understand what you say and I do wholeheartedly agree with you. > > > > However if one would have to strictly follow what has been voted, such > features should be backported to whatever becomes 5.7, if any. Perhaps the > 5.7 RFC could explicitly states what is (not) going to happen wrt those > RFCs. > > I think it’s pretty clear in stating 5.7 will have no new features. > >
I don't think that we have a consensus on that yet, I would put that up for voting, but I do agree that there shouldn't be any major features like what we used to have in a minor version(and I can understand the reasoning from Zeev to even push the small features to 7.0 instead so people have more reason to upgrade).
-- Ferenc Kovács @Tyr43l - http://tyrael.hu

Ferenc Kovacs

11 years ago
On Tue, Dec 16, 2014 at 12:03 PM, Andrea Faulds <ajf@ajf.me> wrote:
> > Hey Matteo, > > > On 16 Dec 2014, at 10:52, Matteo Beccati <php@beccati.com> wrote: > > > > On 16/12/2014 08:55, Andrea Faulds wrote: > >> Could you tell me which RFCs targeted 5.7 and didn’t just add > deprecation notices? I’m unaware of any. > > > > I've tried to search the ML for such list of RFCs: > > > > https://wiki.php.net/rfc/gc_fn_pointer > > https://wiki.php.net/rfc/secure_unserialize (also 5.6 if RMs agree) > > https://wiki.php.net/rfc/closure_apply > > https://wiki.php.net/rfc/pack_unpack_64bit_formats (targeting 5.6) > > https://wiki.php.net/rfc/intdiv > > https://wiki.php.net/rfc/session.user.return-value > > > > maybe others too, but I got bored ;) > > I wrote the Closure::call() and intdiv() RFCs. Truth be told, they both > targeted master, not a specific PHP version. master has become PHP 7, so > whatever the wording of them said, they really target PHP 7 now. They were > written back before the whole PHP 7/phpng thing when I didn’t know whether > we were going to go straight to PHP 7 or whether there’d be another minor > and then PHP 7 a year or two after. Now we’re going straight to PHP 7 - the > 5.7 proposed wouldn’t be an exception to that, as 5.7 would have no new > features and be released around the same time. It’s not, well, the 5.7 I > had in mind when I wrote those RFCs. > >
could you please update the rfc and the intdiv page to move the target version to 7.0?
-- Ferenc Kovács @Tyr43l - http://tyrael.hu

Stas Malyshev

11 years ago
Hi!
> I've tried to search the ML for such list of RFCs: > > https://wiki.php.net/rfc/gc_fn_pointer > https://wiki.php.net/rfc/secure_unserialize (also 5.6 if RMs agree) > https://wiki.php.net/rfc/closure_apply > https://wiki.php.net/rfc/pack_unpack_64bit_formats (targeting 5.6) > https://wiki.php.net/rfc/intdiv > https://wiki.php.net/rfc/session.user.return-value > > maybe others too, but I got bored ;)
Didn't I hear "no features"? Most of these are features.
-- Stas Malyshev smalyshev@gmail.com

Adam Harvey

11 years ago
On 16 December 2014 at 10:38, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>> I've tried to search the ML for such list of RFCs: >> >> https://wiki.php.net/rfc/gc_fn_pointer >> https://wiki.php.net/rfc/secure_unserialize (also 5.6 if RMs agree) >> https://wiki.php.net/rfc/closure_apply >> https://wiki.php.net/rfc/pack_unpack_64bit_formats (targeting 5.6) >> https://wiki.php.net/rfc/intdiv >> https://wiki.php.net/rfc/session.user.return-value >> >> maybe others too, but I got bored ;) > > Didn't I hear "no features"? Most of these are features.
True, but none of them have been accepted for _this_ 5.7. As Andrea said, her "5.7" RFCs simply used that as a placeholder for what is now 7.0, since that was the master version number at the time. The same is true of Sara's session return value RFC. The new pack and unpack formats are in 5.6 already, I believe, so wouldn't be new to 5.7. Secure unserialise was your RFC, so you tell us. :) The only one that's pending and actually applies here is the GC function pointer RFC. As co-proposer, I'd obviously like to see it in 5.7 as well (there's no user impact, it's so trivial it probably doesn't even qualify for copyright protection, and it's useful for profilers), but I'm happy to accept that it might be a casualty of the "no features" rule. In summary: our current state would allow us to have a "no features" rule and for it to make sense with what's already been accepted. Adam

Ferenc Kovacs

11 years ago
On Tue, Dec 16, 2014 at 8:52 AM, Matteo Beccati <php@beccati.com> wrote:
> > On 16/12/2014 05:07, Xinchen Hui wrote: > >> On Tue, Dec 16, 2014 at 8:09 AM, Andrea Faulds <ajf@ajf.me> wrote: >> >>> Good evening, >>> >>> There has been some debate about whether to make “PHP 5.7". I have made >>> a very simple RFC. It proposes a final minor version of PHP 5, PHP 5.7, to >>> be released at the same time as PHP 7, with no new features whatsoever. >>> >>> I am wondering why we need that? no new features.... >> >> I think we can extend 5.6 release cycle to avoid that.. >> > > I tend to agree with Xinchen here. A new minor release just to introduce a > few deprecation messages? It sounds like a lot of work (it also need to be > maintained) for little gain. > > I think that doesn't also match the plans of other (accepted?) RFCs that > were targeted for 5.7. I think I've seen it many times. > > >
We already has one accepted RFC which targets 5.7, and as I mentioned before 5.7.0 wouldn't be featureless, but would contain the small self-contained features which are currently targeting 5.6.x. So 5.7.0 would be a minor version without new major features, but also no BC break, would allow us to make 5.6 more stable, and be a stepping stone for 7.0 with the deprecated errors.
-- Ferenc Kovács @Tyr43l - http://tyrael.hu

Andrew Faulds

11 years ago
Hey,
> On 16 Dec 2014, at 07:58, Ferenc Kovacs <tyra3l@gmail.com> wrote: > > We already has one accepted RFC which targets 5.7, and as I mentioned before 5.7.0 wouldn't be featureless, but would contain the small self-contained features which are currently targeting 5.6.x. > So 5.7.0 would be a minor version without new major features, but also no BC break, would allow us to make 5.6 more stable, and be a stepping stone for 7.0 with the deprecated errors.
That’s a benefit I hadn’t considered: people using distros are stuck on a specific micro, so anything added to 5.6.x they’ll be able to get with 5.7.0, right?
-- Andrea Faulds http://ajf.me/

Ferenc Kovacs

11 years ago
On Tue, Dec 16, 2014 at 9:00 AM, Andrea Faulds <ajf@ajf.me> wrote:
> > Hey, > > > On 16 Dec 2014, at 07:58, Ferenc Kovacs <tyra3l@gmail.com> wrote: > > > > We already has one accepted RFC which targets 5.7, and as I mentioned > before 5.7.0 wouldn't be featureless, but would contain the small > self-contained features which are currently targeting 5.6.x. > > So 5.7.0 would be a minor version without new major features, but also > no BC break, would allow us to make 5.6 more stable, and be a stepping > stone for 7.0 with the deprecated errors. > > That’s a benefit I hadn’t considered: people using distros are stuck on a > specific micro, so anything added to 5.6.x they’ll be able to get with > 5.7.0, right? > >
yep.
-- Ferenc Kovács @Tyr43l - http://tyrael.hu

Zeev Suraski

11 years ago
> -----Original Message----- > From: Andrea Faulds [mailto:ajf@ajf.me] > Sent: Tuesday, December 16, 2014 10:00 AM > To: Ferenc Kovacs > Cc: Matteo Beccati; Xinchen Hui; PHP Internals > Subject: Re: [PHP-DEV] [RFC] PHP 5.7 > > Hey, > > > On 16 Dec 2014, at 07:58, Ferenc Kovacs <tyra3l@gmail.com> wrote: > > > > We already has one accepted RFC which targets 5.7, and as I mentioned > before 5.7.0 wouldn't be featureless, but would contain the small self- > contained features which are currently targeting 5.6.x. > > So 5.7.0 would be a minor version without new major features, but also > > no > BC break, would allow us to make 5.6 more stable, and be a stepping stone > for 7.0 with the deprecated errors. > > That’s a benefit I hadn’t considered: people using distros are stuck on a > specific micro, so anything added to 5.6.x they’ll be able to get with > 5.7.0, > right?
I'm missing what benefit this gives us. Distros lock the version (all 3 digits) for a particular distro version; At the same time, when a new version of the distro comes out, there are no version restrictions of any kind. So for a given distro that uses 5.6.8 (as an example), upgrading to 5.6.9 or 5.7.0 or even 7.0.0 is equally forbidden within the same distro version, and equally allowed within a new distro version. Zeev

Pierre Joye

11 years ago
On Dec 16, 2014 9:10 PM, "Zeev Suraski" <zeev@zend.com> wrote:
> > > -----Original Message----- > > From: Andrea Faulds [mailto:ajf@ajf.me] > > Sent: Tuesday, December 16, 2014 10:00 AM > > To: Ferenc Kovacs > > Cc: Matteo Beccati; Xinchen Hui; PHP Internals > > Subject: Re: [PHP-DEV] [RFC] PHP 5.7 > > > > Hey, > > > > > On 16 Dec 2014, at 07:58, Ferenc Kovacs <tyra3l@gmail.com> wrote: > > > > > > We already has one accepted RFC which targets 5.7, and as I mentioned > > before 5.7.0 wouldn't be featureless, but would contain the small self- > > contained features which are currently targeting 5.6.x. > > > So 5.7.0 would be a minor version without new major features, but also > > > no > > BC break, would allow us to make 5.6 more stable, and be a stepping
stone
> > for 7.0 with the deprecated errors. > > > > That’s a benefit I hadn’t considered: people using distros are stuck on
a
> > specific micro, so anything added to 5.6.x they’ll be able to get with > > 5.7.0, > > right? > > I'm missing what benefit this gives us. > > Distros lock the version (all 3 digits) for a particular distro version;
At
> the same time, when a new version of the distro comes out, there are no > version restrictions of any kind. > > So for a given distro that uses 5.6.8 (as an example), upgrading to 5.6.9
or
> 5.7.0 or even 7.0.0 is equally forbidden within the same distro version,
and
> equally allowed within a new distro version.
And given that many distros have a faster adoption rate, many will adopt 5.7, with notifications for the 7 changes, in their next release as they may be more looking for 6.1 than 6.0. To support this fact, see the recent adoption rate of all major versions since we adopted the release process RFC. One of its goal has been achieved.

Stas Malyshev

11 years ago
Hi!
> There has been some debate about whether to make “PHP 5.7". I have > made a very simple RFC. It proposes a final minor version of PHP 5, > PHP 5.7, to be released at the same time as PHP 7, with no new > features whatsoever. > > The hope is that we can put this to a vote in 2 weeks’ time and > settle the matter, just as we did with the PHP 6/7 name vote, > although perhaps slightly less messily this time. ;)
It'd be nice to describe what we have now for 5.7 - i.e. which deprecation messages and other warnings are on the agenda? Doesn't have to be the exclusive list but at least to give the idea what we're talking about.
-- Stas Malyshev smalyshev@gmail.com

Andrew Faulds

11 years ago
Hey Stas,
> On 16 Dec 2014, at 09:25, Stanislav Malyshev <smalyshev@gmail.com> wrote: > >> There has been some debate about whether to make “PHP 5.7". I have >> made a very simple RFC. It proposes a final minor version of PHP 5, >> PHP 5.7, to be released at the same time as PHP 7, with no new >> features whatsoever. >> >> The hope is that we can put this to a vote in 2 weeks’ time and >> settle the matter, just as we did with the PHP 6/7 name vote, >> although perhaps slightly less messily this time. ;) > > It'd be nice to describe what we have now for 5.7 - i.e. which > deprecation messages and other warnings are on the agenda? Doesn't have > to be the exclusive list but at least to give the idea what we're > talking about.
At the moment, there’s Levi’s RFC to disallow multiple defaults in switch statements, which adds an E_DEPRECATED notice in 5.7. I don’t think there’s anything else. It might be worth adding some sort of warning for Nikita’s Remove alternative PHP tags RFC. Perhaps also for the Integer Semantics RFC, warning that shifts by negative numbers of bits will be disallowed in PHP 7, or for the Fix list() behaviour inconsistency RFC since strings won’t work in list() now.
-- Andrea Faulds http://ajf.me/

Matteo Beccati

11 years ago
Hi Andrea, On 16/12/2014 12:10, Andrea Faulds wrote:
>> It'd be nice to describe what we have now for 5.7 - i.e. which >> deprecation messages and other warnings are on the agenda? Doesn't have >> to be the exclusive list but at least to give the idea what we're >> talking about. > > At the moment, there’s Levi’s RFC to disallow multiple defaults in switch statements, which adds an E_DEPRECATED notice in 5.7. > > I don’t think there’s anything else. It might be worth adding some sort of warning for Nikita’s Remove alternative PHP tags RFC. Perhaps also for the Integer Semantics RFC, warning that shifts by negative numbers of bits will be disallowed in PHP 7, or for the Fix list() behaviour inconsistency RFC since strings won’t work in list() now.
I was initially very much in favour of a 5.7 release, but given the current lack of big BC breaks I'm not so sure. I can even run a dinosaur like Revive on PHP7! If the list of BC breaks grows (e.g. PHP4 constructors -- which I seriously hope doesn't pass -- or other big / evil ones), then I could change my mind once again, but as of now I personally see little gain in a PHP 5.7. That said, I think an RFC is good, but we should run the vote only when we know exactly when PHP7 is going to be, so that everyone can make an informed decision. Doing it now could be premature. Cheers
-- Matteo Beccati Development & Consulting - http://www.beccati.com/

Levi Morrison

11 years ago
> I was initially very much in favour of a 5.7 release, but given the current > lack of big BC breaks I'm not so sure. I can even run a dinosaur like Revive > on PHP7! > > If the list of BC breaks grows (e.g. PHP4 constructors -- which I seriously > hope doesn't pass -- or other big / evil ones), then I could change my mind > once again, but as of now I personally see little gain in a PHP 5.7.
Support in general has been overwhelmingly in favor of removing PHP 4 constructors. It should go to vote soonish and then we'll have a better idea.

Ferenc Kovacs

11 years ago
On Tue, Dec 16, 2014 at 10:25 AM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> > Hi! > > > There has been some debate about whether to make “PHP 5.7". I have > > made a very simple RFC. It proposes a final minor version of PHP 5, > > PHP 5.7, to be released at the same time as PHP 7, with no new > > features whatsoever. > > > > The hope is that we can put this to a vote in 2 weeks’ time and > > settle the matter, just as we did with the PHP 6/7 name vote, > > although perhaps slightly less messily this time. ;) > > It'd be nice to describe what we have now for 5.7 - i.e. which > deprecation messages and other warnings are on the agenda? Doesn't have > to be the exclusive list but at least to give the idea what we're > talking about. >
Just an initial list, feel free to extend it: - we could add an E_DEPRECATED for zpp overflow: https://wiki.php.net/rfc/zpp_fail_on_overflow - if we could trigger E_DEPRECATED for function foo($x,$x) {} which is now a compile error thanks to https://wiki.php.net/phpng that would be nice - if we could cover some of the BC breaks with E_DEPRECATED from https://wiki.php.net/rfc/uniform_variable_syntax#backward_incompatible_changes that would be nice, but not sure if feasible. - if we could trigger E_DEPRECATED for list()-ing a string which will be removed in 7.0(https://wiki.php.net/rfc/fix_list_behavior_inconsistency) that would be nice. - E_DEPRECATED for the alternative php tags which will be removed with 7.0(https://wiki.php.net/rfc/remove_alternative_php_tags). - merge https://github.com/php/php-src/pull/807 for adding E_DEPRECATED for multiple default labels in switch. - maybe we could add an E_DEPRECATED for https://wiki.php.net/rfc/session.user.return-value to notify authors of custom session handlers( https://wiki.php.net/rfc/session.user.return-value) - please note that the vote for this change was in favour for changing it in 5.7, so if we don't overrule the decision, we don't add the deprecated message, but the BC break instead.
-- Ferenc Kovács @Tyr43l - http://tyrael.hu