[RFC] PHP 5.7

9 years ago by Adam Harvey — view source

unread

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

9 years ago by Andrea Faulds — view source

unread

Hi Adam,

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/

9 years ago by Kris Craig — view source

unread

Hi Adam,

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/

--

+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

9 years ago by Andrea Faulds — view source

unread

Hi everyone,

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.

+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.

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/

9 years ago by Xinchen Hui — view source

unread

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/

--

--
Xinchen Hui
@Laruence
http://www.laruence.com/

9 years ago by Andrea Faulds — view source

unread

Hi Xinchen,

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/

9 years ago by Levi Morrison — view source

unread

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.

9 years ago by Lester Caine — view source

unread

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

9 years ago by Zeev Suraski — view source

unread

-----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

9 years ago by Ferenc Kovacs — view source

unread

-----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

9 years ago by Zeev Suraski — view source

unread

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.

9 years ago by Ferenc Kovacs — view source

unread

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

9 years ago by Rowan Collins — view source

unread

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]

9 years ago by Florian Margaine — view source

unread

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

9 years ago by Julien Pauli — view source

unread

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

9 years ago by Zeev Suraski — view source

unread

-----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

9 years ago by Adam Harvey — view source

unread

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?

None, but I'd still advocate releasing a new minor because there's
plenty of anecdata suggesting that our userbase tend to consider 5.x.y
and 5.x.y+z to be the same in terms of features. We used to see this
confusion in ##php a lot over things like crypt() algorithm support
changing over the course of 5.3: trying to explain that you don't want
to use anything before 5.3.7 is actually surprisingly difficult,
whereas saying "5.4 fixes this" is easy.

Adam

9 years ago by Zeev Suraski — view source

unread

-----Original Message-----
From: adam@adamharvey.name [mailto:adam@adamharvey.name] On
Behalf Of Adam Harvey
Sent: Wednesday, December 17, 2014 12:10 AM
To: Zeev Suraski
Cc: 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?

None, but I'd still advocate releasing a new minor because there's plenty
of
anecdata suggesting that our userbase tend to consider 5.x.y and 5.x.y+z
to
be the same in terms of features. We used to see this confusion in ##php a
lot over things like crypt() algorithm support changing over the course of
5.3:
trying to explain that you don't want to use anything before 5.3.7 is
actually
surprisingly difficult, whereas saying "5.4 fixes this" is easy.

I actually agree with that.

My view, though, that if we think that delivering those deprecation messages
is critical, we're facing a choice between two less-than-ideal options. The
5.7 option defeats the purpose for which it's built - getting a substantial
number of people to upgrade and see those messages in the first place.
It'll also create an awkward and maybe even silly situation where we'd have
two active versions - both with its own monthly releases, but effectively
virtually identical to each other in every regard except for these messages.

Zeev

9 years ago by Adam Harvey — view source

unread

-----Original Message-----
From: adam@adamharvey.name [mailto:adam@adamharvey.name] On
Behalf Of Adam Harvey
Sent: Wednesday, December 17, 2014 12:10 AM
To: Zeev Suraski
Cc: 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?

None, but I'd still advocate releasing a new minor because there's plenty
of
anecdata suggesting that our userbase tend to consider 5.x.y and 5.x.y+z
to
be the same in terms of features. We used to see this confusion in ##php a
lot over things like crypt() algorithm support changing over the course of
5.3:
trying to explain that you don't want to use anything before 5.3.7 is
actually
surprisingly difficult, whereas saying "5.4 fixes this" is easy.

My view, though, that if we think that delivering those deprecation messages
is critical, we're facing a choice between two less-than-ideal options. The
5.7 option defeats the purpose for which it's built - getting a substantial
number of people to upgrade and see those messages in the first place.

I think it's actually more likely that people will upgrade to a new
minor than a later revision that includes deprecation warnings in the
long run. There's a decent amount of evidence that suggests that users
tend to stick to their distro packages for minors, and those tend to
be early in the minor cycle (the various version links at
http://w3techs.com/technologies/details/pl-php/5/all are interesting,
and I've seen non-public data that indicates the same thing).

It'll also create an awkward and maybe even silly situation where we'd have
two active versions - both with its own monthly releases, but effectively
virtually identical to each other in every regard except for these messages.

For twelve months, until 5.6 enters extended support. I think that's
manageable, and although it might seem silly internally, I think it's
also a better result for our users in terms of managing their
migration paths.

Adam, who's pretty much going to bow out of the conversation for now,
since he's said everything he wanted to.

9 years ago by Zeev Suraski — view source

unread

From: adam@adamharvey.name [mailto:adam@adamharvey.name] On
Behalf Of Adam Harvey
Sent: Wednesday, December 17, 2014 12:29 AM
To: Zeev Suraski
Cc: PHP Internals
Subject: Re: [PHP-DEV] [RFC] PHP 5.7

I think it's actually more likely that people will upgrade to a new minor
than a
later revision that includes deprecation warnings in the long run. There's
a
decent amount of evidence that suggests that users tend to stick to their
distro packages for minors, and those tend to be early in the minor cycle
(the
various version links at http://w3techs.com/technologies/details/pl-
php/5/all are interesting, and I've seen non-public data that indicates
the
same thing).

Both my experience and interpretation of the numbers is quite different.
Companies consider migration to new minor versions as a relatively painful
one, that requires a full cycle of QA and expect changes to be made. Even
though that's been less and less true in recent years, that's still
perception. That's why penetration of ALL newer versions of PHP combined is
still less of that of 5.3, and why despite the fact migration from 5.4 to
5.5 or 5.6 is quite painless, there are a lot more people on 5.4 than there
are on 5.5/5.6 (and not on any one distro version as far as I can tell, just
the most recent ones). Even on 5.5, the distro version (5.5.9) accounts for
30%, while other versions account for 70% - with the most recent ones
(5.5.16 through 5.5.19) accounting for 42% combined - that's almost 8 times
5.6's entire footprint (you can see similar breakdowns for 5.3 as well - 22%
for the distro version vs. 46% for the most recent 5.3 versions). Companies
(and users) are simply a lot less wary of 3rd digit upgrades than 2nd digit
ones.

For twelve months, until 5.6 enters extended support. I think that's
manageable, and although it might seem silly internally, I think it's also
a
better result for our users in terms of managing their migration paths.

I think it looks silly externally, I don't think we should care much about
internal silliness.

Zeev

9 years ago by Ferenc Kovacs — view source

unread

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.

we don't have much or really big ones(yet), we have a couple of nasty ones
(eg. doesn't blow up, but behaves differently, check the mails from Derick
complaining about those).
and there are a couple ones upcoming/likely to make it through:
https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7
https://wiki.php.net/rfc/remove_php4_constructors

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.

while I hope that you are right, but I think that PHP7 will be really
interesting for two kind of people:

people who are looking for performance gains, even if it makes
rewriting some code (and those who can this way have a feasible alternative
instead of moving to hhvm/hack).
people who wants to start a greenfield project and for some reason
they already decided to do in in php (because they already invested into
the technology or because php is a really good choice for their usecase)
and they are able to control their infrastructure so that they can have 7.0
on it.
they really need a feature which only 7.0 has and doing it in userland
would be too hard to do or unfeasible (not sure if we have something like
this in 7.0).

Worst case the others will probably upgrade in the same tempo as they are
currently doing or the way they did with php4 vs php5.
I think that the only thing which really had an impact on the adoption
rates is the fact that we provided stuff what modern frameworks/apps needed
and made it easier to users/distros to upgrade.
I think it is important to not forget those, and sometimes I feel that we
are focus too much on shipping PHP7 only with the performance gains already
present or to force people to upgrade (instead making sure that we provide
what they want and the easiest upgrade path possible).

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.

fortunately we already have a couple of those for some of the nasty changes
like https://gist.github.com/nikic/ffd019ef78b72934c7cc for finding code
which would be affected by the behavior change of
https://wiki.php.net/rfc/uniform_variable_syntax
I do think that while those kind of extra steps are not mandatory per se,
but they help a lot when convincing people to jump the ship and upgrade.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

9 years ago by Derick Rethans — view source

unread

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.

we don't have much or really big ones(yet), we have a couple of nasty
ones (eg. doesn't blow up, but behaves differently, check the mails
from Derick complaining about those).

Those should never have made it into PHP 7 at all. It's like a big "fuck
you" to users.

and there are a couple ones upcoming/likely to make it through:
https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7

I think we should bump up the granularity of the voting options there.
As some I think are ok, for example:

dl on fpm-fcgi (since PHP 5.3)

But others are not:

CN_match and SNI_server_name stream context option (since PHP 5.6;
use peer_name instead) [TODO]

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.

fortunately we already have a couple of those for some of the nasty changes
like https://gist.github.com/nikic/ffd019ef78b72934c7cc for finding code
which would be affected by the behavior change of
https://wiki.php.net/rfc/uniform_variable_syntax
I do think that while those kind of extra steps are not mandatory per se,
but they help a lot when convincing people to jump the ship and upgrade.

I would go as far as making it mandatory if you change bahaviour of
existing syntax that can't be detected through a simple "php -l".

cheers,
Derick

9 years ago by Ferenc Kovacs — view source

unread

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

9 years ago by Andrea Faulds — view source

unread

Hey Florian,

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/

9 years ago by Adam Harvey — view source

unread

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

9 years ago by Pierre Joye — view source

unread

Hey Florian,

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.

9 years ago by Andrea Faulds — view source

unread

Hi Pierre,

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.

I’m not considering dropping the RFC because of opposition. Rather, I think that suggestion is actually better than having a 5.7 release.

Thanks.

Andrea Faulds
http://ajf.me/

9 years ago by Pierre Joye — view source

unread

Hi Pierre,

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.

I’m not considering dropping the RFC because of opposition. Rather, I think that suggestion is actually better than having a 5.7 release.

Pretty much the same result, isn't it? There are many voices in favor
of 5.7, for very good reasons (see the distros one for the most
important). An extension will be useless, no impact, defeat the main
goal of having a 5.7. And an extension will require much more work
than having 5.7, given that "the amount of work" is the main argument
against 5.7, I find it disturbing.

--
Pierre

@pierrejoye | http://www.libgd.org

9 years ago by Michael Wallner — view source

unread

Hi Pierre,

On 16 Dec 2014, at 23:42, Pierre Joye pierre.php@gmail.com
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.

Please do not.

I’m not considering dropping the RFC because of opposition. Rather, I
think that suggestion is actually better than having a 5.7 release.

I'd definitely be in favor of concentrating on 7.0 and rather have
external supportive tools instead of an 5.7 release.

--
Regards,
Mike

9 years ago by Ferenc Kovacs — view source

unread

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

9 years ago by Zeev Suraski — view source

unread

-----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

9 years ago by Ferenc Kovacs — view source

unread

-----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 :)

I was just pointing out, that we don't have a consensus on this decision.
If I'm the minority with my opinion I will accept it, I just wanted to make
sure that this kind of the discussion is not wrongly
summarized/misrepresented. I do remember seeing other people who liked the
idea of having small self-contained features, and from the top of my head I
could only name you who was on the side of the fence that there should be
no new features at all, even in 5.6, and everybody should just work on 7.0.

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.

I think that it is sometimes better to first have a discussion before
trying to put out competing RFCs if you think that there are some
points/aspects which you seem to not agree on. (Usually this is the point
of the Under Discussion status of the RFCs).

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).

could you clarify one thing for me?
from that sentence it seems that you aren't really against having small new
features (as those are already happened/happening in 5.6.x and you did not
mention that you have a problem with that) but you think that there would
be more/bigger features happening if there would be an 5.7 version?
do I understand you correctly?
If you have problems with small improvements happening anywhere but in 7.0,
I think we should have a vote on that, because we don't really have a clean
rule to prevent that from happening (or you can convince the RMs to veto
every feature on the current 5.x branches).
if you have problem with 5.7 growing in complexity/number of features I
think that wouldn't really be a problem, as for one we would have a more
formal process for approving the features what is currently happening
(people asking the RMs if they think this or that is okay and in which
branch should it go), plus I don't think that many people would really want
to implement a complex feature twice (once against 5.7 and once against
7.0) which will be available in both versions around the same time (maybe a
couple of months sooner in 5.7).
Personally I don't expect more development going into 5.6+5.7 than what is
currently happening in 5.6.
I think this PR/mail is a good example how would having a clear target for
small improvements help:
internals@lists.php.net/msg71998.html" rel="nofollow" target="_blank">https://www.mail-archive.com/internals@lists.php.net/msg71998.html

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

9 years ago by Zeev Suraski — view source

unread

could you clarify one thing for me?

from that sentence it seems that you aren't really against having small new
features (as those are already happened/happening in 5.6.x and you did not
mention that you have a problem with that) but you think that there would
be more/bigger features happening if there would be an 5.7 version?

I’m opposed to having a 5.7 release that has new features on top of 5.6.x.
There should be no new feature release in the 5.x line beyond 5.6.x.

I also think we should minimize any new work on 5.6.x as much as possible,
and focus all of our efforts on 7.0.

9 years ago by Sebastian Bergmann — view source

unread

Am 17.12.2014 um 15:54 schrieb Zeev Suraski:

I’m opposed to having a 5.7 release that has new features on
top of 5.6.x.

Same here; 5.7 should only add deprecations etc. and must not add new
features.

I also think we should minimize any new work on 5.6.x as much as
possible, and focus all of our efforts on 7.0.

PHP 5.6.X must not get any more new features and should only receive
bug fixes. The only real work I see for PHP 5.7 is to decide which
deprecations etc. to add. The actual implementation of those should
be trivial.

9 years ago by Levi Morrison — view source

unread

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.

9 years ago by Pierre Joye — view source

unread

-----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.

9 years ago by Matteo Beccati — view source

unread

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/

9 years ago by Andrea Faulds — view source

unread

Hi Matteo,

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/

9 years ago by Matteo Beccati — view source

unread

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/

9 years ago by Andrea Faulds — view source

unread

Hey Matteo,

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/

9 years ago by Matteo Beccati — view source

unread

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/

9 years ago by Andrea Faulds — view source

unread

Hey Matteo,

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/

9 years ago by Ferenc Kovacs — view source

unread

Hey Matteo,

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

9 years ago by Ferenc Kovacs — view source

unread

Hey Matteo,

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

9 years ago by Stanislav Malyshev — view source

unread

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

9 years ago by Adam Harvey — view source

unread

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

9 years ago by Ferenc Kovacs — view source

unread

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

9 years ago by Andrea Faulds — view source

unread

Hey,

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/

9 years ago by Ferenc Kovacs — view source

unread

Hey,

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

9 years ago by Zeev Suraski — view source

unread

-----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,

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

9 years ago by Pierre Joye — view source

unread

-----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,

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.

9 years ago by Stanislav Malyshev — view source

unread

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

9 years ago by Andrea Faulds — view source

unread

Hey Stas,

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/

9 years ago by Matteo Beccati — view source

unread

Hi Andrea,

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/

9 years ago by Levi Morrison — view source

unread

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.

9 years ago by Ferenc Kovacs — view source

unread

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

Thanks!

Thanks!

Thanks!

Thanks!

Thanks.

-- Lester Caine - G8HFL

Regards,

Thanks.

Cheers

Thanks.

Cheers

I don’t really know about the session handling and GC ones.

Cheers

Thanks,

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.

Cheers

--
Lester Caine - G8HFL

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.