Hi internals,
Based on some recent conversations, I'm getting the impression that after
PHP 7.3, we might want to go for PHP 8 next.
I'd like to discuss and possibility decide this now, as that would make PHP
7.3 the last chance to get in deprecations.
Nikita
Based on some recent conversations, I'm getting the impression that after
PHP 7.3, we might want to go for PHP 8 next.I'd like to discuss and possibility decide this now, as that would make PHP
7.3 the last chance to get in deprecations.
Would you mind elaborating on your motivations for a major version
bump. I'm not saying I disagree in principle, I'm just curious what
you're seeing the drivers as.
-Sara
-----Original Message-----
From: php@golemon.com [mailto:php@golemon.com] On Behalf Of Sara
Golemon
Sent: Sunday, June 24, 2018 1:07 AM
To: Nikita Popov nikita.ppv@gmail.com
Cc: PHP internals internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 8 next?Based on some recent conversations, I'm getting the impression that
after PHP 7.3, we might want to go for PHP 8 next.I'd like to discuss and possibility decide this now, as that would
make PHP
7.3 the last chance to get in deprecations.Would you mind elaborating on your motivations for a major version bump. I'm
not saying I disagree in principle, I'm just curious what you're seeing the drivers
as.
This is slightly earlier than I intended to bring it up but I do too think that the next version beyond 7.3 should be 8.
I'll send a more detailed letter next week - but in a nutshell, the main drivers I'm seeing are JIT, FFI and possibly doing something in the front of async/long running processes. Of course there may be other ones as well, but I think that these alone constitute sufficient grounds for launching a new major version.
Zeev
-----Original Message-----
From: php@golemon.com [mailto:php@golemon.com] On Behalf Of Sara
Golemon
Sent: Sunday, June 24, 2018 1:07 AM
To: Nikita Popov nikita.ppv@gmail.com
Cc: PHP internals internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 8 next?Based on some recent conversations, I'm getting the impression that
after PHP 7.3, we might want to go for PHP 8 next.I'd like to discuss and possibility decide this now, as that would
make PHP
7.3 the last chance to get in deprecations.Would you mind elaborating on your motivations for a major version bump. I'm
not saying I disagree in principle, I'm just curious what you're seeing the drivers
as.This is slightly earlier than I intended to bring it up but I do too think that the next version beyond 7.3 should be 8.
I disagree.
I'm mostly a user, not a PHP developer.
RHEL 7.5, the latest version of RHEL, still ships 5.4.
Other LTS distributions also probably ship 5.x.
So a major version bump now would mean three major versions of PHP that
web applications intended to "just work" on enterprise *nix would have
to support.
If there was a major design flaw in PHP that can only truly be fixed by
an incompatible version bump past 7 then do it but otherwise, I think it
would be better to wait until the most recent versions of enterprise
distributions have moved to php 7.
I'm hoping RHEL 8 does, the benefits are tremendous of 7 over 6.x, but...
The issue is some customers of enterprise linux specifically don't want
frankenstein systems and want to use vendor supported packages only, and
I can see their point of view because they pay a lot of money for that
support.
That being said, I try to get everyone running old PHP up to 7.1 or 7.2
even if it means frankenstein systems. But some think the benefit of
enterprise vendor support outweighs the improvements in PHP.
-----Original Message-----
From: php@golemon.com [mailto:php@golemon.com] On Behalf Of Sara
Golemon
Sent: Sunday, June 24, 2018 1:07 AM
To: Nikita Popov nikita.ppv@gmail.com
Cc: PHP internals internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 8 next?On Sat, Jun 23, 2018 at 4:22 PM, Nikita Popov nikita.ppv@gmail.com
wrote:Based on some recent conversations, I'm getting the impression that
after PHP 7.3, we might want to go for PHP 8 next.I'd like to discuss and possibility decide this now, as that would
make PHP
7.3 the last chance to get in deprecations.Would you mind elaborating on your motivations for a major version
bump. I'm
not saying I disagree in principle, I'm just curious what you're seeing
the drivers
as.This is slightly earlier than I intended to bring it up but I do too
think that the next version beyond 7.3 should be 8.I disagree.
I'm mostly a user, not a PHP developer.
RHEL 7.5, the latest version of RHEL, still ships 5.4.
Other LTS distributions also probably ship 5.x.
So a major version bump now would mean three major versions of PHP that
web applications intended to "just work" on enterprise *nix would have
to support.If there was a major design flaw in PHP that can only truly be fixed by
an incompatible version bump past 7 then do it but otherwise, I think it
would be better to wait until the most recent versions of enterprise
distributions have moved to php 7.I'm hoping RHEL 8 does, the benefits are tremendous of 7 over 6.x, but...
The issue is some customers of enterprise linux specifically don't want
frankenstein systems and want to use vendor supported packages only, and
I can see their point of view because they pay a lot of money for that
support.That being said, I try to get everyone running old PHP up to 7.1 or 7.2
even if it means frankenstein systems. But some think the benefit of
enterprise vendor support outweighs the improvements in PHP.--
To unsubscribe, visit: http://www.php.net/ http://www.php.net/unsub.php
unsub.php http://www.php.net/unsub.php
If we’re going to 8 can we please fix the ternary operator now???
Hello,
This is slightly earlier than I intended to bring it up but I do too think that the next version beyond 7.3 should be 8.
I disagree.
I'm mostly a user, not a PHP developer.
RHEL 7.5, the latest version of RHEL, still ships 5.4.
RHEL has official software collections for PHP 7.0 and 7.1. Remi has an SCL for 7.2. We run 7.2 in production and 5.6 is gone in December. 5.4.16 in RHEL was... a mistake. There is nothing “un-enterprise” about the SCLs and they work very well.
RHEL 8 is coming soon and is based on Fedora 28. It will likely ship 7.2, I imagine.
Other LTS distributions also probably ship 5.x.
Ubuntu 16.04 LTS shipped with PHP 7.0. Ubuntu 18.04 LTS ships with PHP 7.2. PHP 5.* was a great line but it has been time to move for a while. It’s getting harder to come up with reasoning to stay. I haven’t come across a codebase that didn’t run on 7+ and this includes a 16 year old codebase that started on PHP 4. It’s an anecdote, but proof that anything is possible.
So a major version bump now would mean three major versions of PHP that web applications intended to "just work" on enterprise *nix would have to support.
For sure, this is the distribution’s choice, not the maintainers here.
If there was a major design flaw in PHP that can only truly be fixed by an incompatible version bump past 7 then do it but otherwise, I think it would be better to wait until the most recent versions of enterprise distributions have moved to php 7.
I'm hoping RHEL 8 does, the benefits are tremendous of 7 over 6.x, but...
The issue is some customers of enterprise linux specifically don't want frankenstein systems and want to use vendor supported packages only, and I can see their point of view because they pay a lot of money for that support.
That being said, I try to get everyone running old PHP up to 7.1 or 7.2 even if it means frankenstein systems. But some think the benefit of enterprise vendor support outweighs the improvements in PHP.
I have Puppet to manage LAMP using httpd24 and php72 on RHEL if you’re interested. Once it is in config management, it’s not “Frankenstein” anymore. And if folks complain about “Frankenstein” systems when their definition of such is using software collections, I would argue their not getting value out of the product provided by RedHat, as SCL versions of PHP are provided by the vendor! Use them!
-Dustin
Based on some recent conversations, I'm getting the impression that
after PHP 7.3, we might want to go for PHP 8 next.I'd like to discuss and possibility decide this now, as that would
make PHP
7.3 the last chance to get in deprecations.Would you mind elaborating on your motivations for a major version bump. I'm
not saying I disagree in principle, I'm just curious what you're seeing the drivers
as.I'll send a more detailed letter next week - but in a nutshell, the main drivers
I'm seeing are JIT, FFI and possibly doing something in the front of
async/long running processes. Of course there may be other ones
as well, but I think that these alone constitute sufficient grounds for
launching a new major version.
Any one of JIT or async/long-running alone would be enough to merit
the bump, so yeah, I'm provisionally on board with that. FFI is cool
and all, but it's also not really a major-bump-worthy feature. I
didn't realize the JIT was to the point that it was showing real
promise. Last update I'd heard was that it was academically
interesting, but underwhelming in practice.
-Sara
-----Original Message-----
From: php@golemon.com [mailto:php@golemon.com] On Behalf Of Sara
Golemon
Sent: Sunday, June 24, 2018 1:07 AM
To: Nikita Popov nikita.ppv@gmail.com
Cc: PHP internals internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 8 next?Based on some recent conversations, I'm getting the impression that
after PHP 7.3, we might want to go for PHP 8 next.I'd like to discuss and possibility decide this now, as that would
make PHP
7.3 the last chance to get in deprecations.Would you mind elaborating on your motivations for a major version bump. I'm
not saying I disagree in principle, I'm just curious what you're seeing the drivers
as.This is slightly earlier than I intended to bring it up but I do too think that the next version beyond 7.3 should be 8.
I'll send a more detailed letter next week - but in a nutshell, the main drivers I'm seeing are JIT, FFI and possibly doing something in the front of async/long running processes. Of course there may be other ones as well, but I think that these alone constitute sufficient grounds for launching a new major version.
Zeev
Neither JIT nor FFI require backwards compatibility breaks in
language. I don't think either of those particular features would
substantially break the C API either. If these are the motivations for
PHP 8 then I strongly object.
Hi
Den søn. 24. jun. 2018 kl. 02.59 skrev Levi Morrison levim@php.net:
Neither JIT nor FFI require backwards compatibility breaks in
language. I don't think either of those particular features would
substantially break the C API either. If these are the motivations for
PHP 8 then I strongly object.
I agree with the objection, however they are also a major selling
point for a major version which I think is something worth keeping in
mind.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Neither JIT nor FFI require backwards compatibility breaks in language. I don't
think either of those particular features would substantially break the C API
either. If these are the motivations for PHP 8 then I strongly object.
Backwards compatibility breakages have never been the trigger for bumping into a major release. They were allowed in case a major release was made available - for different reasons.
The trigger for a major release has always been very substantial improvements/changes to the language, which I believe JIT, FFI and potentially async squarely fit into (and I'll explain why I think that separately later this week). This is true for PHP 3, 4, 5 and 7 (even though 3 and 5 did introduce inherent compatibility breakages as a part of its new functionality).
Just to provide an example, PHP 7 could have been close to 100.0% downwards compatible (not significantly more incompatible than other minor versions) - in fact when we worked on the phpng engine we went out of our ways to keep it downwards compatible. The way things flowed was that once we had this major-version-material in the form of a radically faster engine - we decided it was going to be a major version indeed, and this opened the door to introducing compatibility breaking changes as per our release policy. Not the other way around.
Zeev
Neither JIT nor FFI require backwards compatibility breaks in language. I don't
think either of those particular features would substantially break the C API
either. If these are the motivations for PHP 8 then I strongly object.Backwards compatibility breakages have never been the trigger for bumping into a major release. They were allowed in case a major release was made available - for different reasons.
The trigger for a major release has always been very substantial improvements/changes to the language, which I believe JIT, FFI and potentially async squarely fit into (and I'll explain why I think that separately later this week). This is true for PHP 3, 4, 5 and 7 (even though 3 and 5 did introduce inherent compatibility breakages as a part of its new functionality).
My position stands: I strongly object. If we rush to PHP 8 then it
will be at least 4-5 more years before we have another chance for
breakages in PHP 9. We can add features yearly.
My position stands: I strongly object. If we rush to PHP 8 then it
will be at least 4-5 more years before we have another chance for
breakages in PHP 9. We can add features yearly.
Then when is the right time? We already have a list of deprecated features, and I believe some have already waited 4 years.
Are there particular breaking changes that you think would be ready in 2 years time that wouldn't be ready in 1?
I've argued before that there should be a roadmap and a cycle for major releases, and if not, then some agreement on what triggers one, but we've so far not managed to agree either.
Regards,
--
Rowan Collins
[IMSoP]
On 24.06.2018 at 19:23, Rowan Collins:
I've argued before that there should be a roadmap and a cycle for major releases, and if not, then some agreement on what triggers one, […]
Hear! Hear!
In my opnion, this should already have been part of the “Release
Process” RFC[1], and since it hasn't, we should really catch up on that.
[1] https://wiki.php.net/rfc/releaseprocess
--
Christoph M. Becker
My position stands: I strongly object. If we rush to PHP 8 then it
will be at least 4-5 more years before we have another chance for
breakages in PHP 9. We can add features yearly.Then when is the right time? We already have a list of deprecated features, and I believe some have already waited 4 years.
Are there particular breaking changes that you think would be ready in 2 years time that wouldn't be ready in 1?
Certainly. Large breaks require multi-year planning and multiple
releases to add migration paths, documentation and training,
deprecations, etc, before the change itself happens. If PHP 8 is the
next release then we've missed the window for deprecations and
warnings (mostly; feature freeze is imminent).
I wish our symbol tables were merged. If they were they we could
nicely solve some issues:
// this tries to use a constant of name 'functionname'
array_map(functionname, $input);
// this uses an object property instead of a method
array_map($object->methodname, $input);
// requires parens; eg ($this->property_which_is_callable)(...$args)
$this->property_which_is_callable(...$args);
Another: people would like autoloading to work with functions and
constants instead of just classes/interfaces/traits. It's also
annoying that we have to re-implement features for every symbol type
"use function", "use const", whereas classes just say "use". It's also
annoying that our symbols do not behave the same when they are
missing; again, unifying the behaviors is a bonus and lays the
foundation for other features.
Whether you actually want these features or not, hopefully you can
agree that these things cannot be dropped into PHP 8 without warnings
and deprecations, which is our most reliable way of telling users when
code will break or change.
Hi Levi,
Are there particular breaking changes that you think would be ready
in 2 years time that wouldn't be ready in 1?Certainly. Large breaks require multi-year planning and multiple
releases to add migration paths, documentation and training,
deprecations, etc, before the change itself happens. If PHP 8 is the
next release then we've missed the window for deprecations and
warnings (mostly; feature freeze is imminent).
That makes sense. :)
What do you think about planning 8.0 for 2020, which gives us a year
to build those plans into 7.4?
I think it would be good to set a specific target, even if only
approximately, so that we don't just have the same discussion in a
year's time.
I wish our symbol tables were merged. If they were they we could
nicely solve some issues...
I'm not entirely sure what deprecation would look like for this, but I
guess that makes it a perfect example of something that needs time to
plan. :)
Regards,
Rowan Collins
[IMSoP]
I've argued before that there should be a roadmap and a cycle for major releases, and if not, then some agreement on what triggers one, but we've so far not managed to agree either.
I do believe a road map and a cycle is a good idea. I'm hearing some
complaints from on the ground that releases are currently too frequent,
making it difficult for larger organisations to keep up when they have
to retest all their own apps/libraries/plugins with the new versions.
A fixed cycle and schedule could help plan for change.
--
Mark Baker
|. \ -3
|J/ PHP |
|| | __ |
|| |m| |m|
I LOVE PHP
I've argued before that there should be a roadmap and a cycle for major
releases, and if not, then some agreement on what triggers one, but we've
so far not managed to agree either.I do believe a road map and a cycle is a good idea. I'm hearing some
complaints from on the ground that releases are currently too frequent,
making it difficult for larger organisations to keep up when they have
to retest all their own apps/libraries/plugins with the new versions.A fixed cycle and schedule could help plan for change.
--
Mark Baker
|. \ -3
|J/ PHP |
|| | __ |
|| |m| |m|I LOVE PHP
--
I'd like to put in my two cents as someone in userland that isn't really
involved with the development lifecycle of PHP. I'm aware that my opinions
might not be shared by others, so I'm not claiming to speak for anyone else.
I've always viewed major releases as "This has MAJOR changes to the
backbone of PHP" - Old code is more likely to break during a major update,
but, doesn't have too. Minor releases, on the other hand, are more about
fixing the bigger bugs and introducing some new functionality, but nothing
ground-breaking. While still possible, the chances of old code breaking
should be pretty small. Changing that third number is just about security
and bug fixes.
Let me expand on two of those points:
1.) Old code breaks during minor updates. We upgraded to 7.0 AFTER 7.1 was
released, because we had already made major updates to upgrade to 7.0, and
7.1 introduced a few things that would have broken our code - we didn't
have time to fix those by that point. "Throw on passing too few function
arguments" would actually break more stuff in our legacy code than all of
the 7.0 changes combined.
2.) JIT, FFI, and Async are things I'd consider "major changes to the
backbone of PHP" just like the overhauled engine in PHP 7.
Finally, I personally see the idea of a deprecation only release to be kind
of silly. I don't work for a software company. It's tough enough for me to
make a case for upgrading using the "increase performance" and "new
features" argument. There is no way I'd get the go-ahead to do an upgrade
that would just make additional features deprecated. It would be a better
use of my time to look for and fix the deprecated features as part of the
8.0 upgrade prep, than to upgrade to 7.4. Maybe look at at backporting some
of the new 8.0 features that aren't really dependent on the major things
like JIT, async, etc., as part of the 7.4 release.
--
-- Chase
chasepeeler@gmail.com
1.) Old code breaks during minor updates. We upgraded to 7.0 AFTER 7.1 was
released, because we had already made major updates to upgrade to 7.0, and
7.1 introduced a few things that would have broken our code - we didn't
have time to fix those by that point. "Throw on passing too few function
arguments" would actually break more stuff in our legacy code than all of
the 7.0 changes combined.
I agree. It was a bad decision on our part to do it in 7.1 - this bit a
lot of users.
Finally, I personally see the idea of a deprecation only release to be kind
of silly. I don't work for a software company. It's tough enough for me to
make a case for upgrading using the "increase performance" and "new
features" argument. There is no way I'd get the go-ahead to do an upgrade
that would just make additional features deprecated. It would be a better
use of my time to look for and fix the deprecated features as part of the
8.0 upgrade prep, than to upgrade to 7.4. Maybe look at at backporting some
of the new 8.0 features that aren't really dependent on the major things
like JIT, async, etc., as part of the 7.4 release.Fair enough, and I think there'll likely be a lot of folks that would see
no point in going through such a 7.4. However, I think that folks working
in more agile companies, or even developers that want to get a head start
on preparing for 8.0 - will find value in such a release. TBH, the vast
majority of users don't upgrade to our minor versions even when they bring
new features and capabilities.
Zeev
On Mon, Jun 25, 2018 at 8:40 PM Chase Peeler chasepeeler@gmail.com
wrote:1.) Old code breaks during minor updates. We upgraded to 7.0 AFTER 7.1
was
released, because we had already made major updates to upgrade to 7.0,
and
7.1 introduced a few things that would have broken our code - we didn't
have time to fix those by that point. "Throw on passing too few function
arguments" would actually break more stuff in our legacy code than all of
the 7.0 changes combined.I agree. It was a bad decision on our part to do it in 7.1 - this bit a
lot of users.Finally, I personally see the idea of a deprecation only release to be
kind
of silly. I don't work for a software company. It's tough enough for me
to
make a case for upgrading using the "increase performance" and "new
features" argument. There is no way I'd get the go-ahead to do an upgrade
that would just make additional features deprecated. It would be a better
use of my time to look for and fix the deprecated features as part of the
8.0 upgrade prep, than to upgrade to 7.4. Maybe look at at backporting
some
of the new 8.0 features that aren't really dependent on the major things
like JIT, async, etc., as part of the 7.4 release.Fair enough, and I think there'll likely be a lot of folks that would see
no point in going through such a 7.4. However, I think that folks working
in more agile companies, or even developers that want to get a head start
on preparing for 8.0 - will find value in such a release. TBH, the vast
majority of users don't upgrade to our minor versions even when they bring
new features and capabilities.
So, about that Ternary operator?
My understanding is that major releases are the only ones allowed to have
breaking changes. Correcting the ternary operator to work like it does in
all other languages is a small example. Merging the symbol tables is
another.
5.3 had namespaces - 5.4 made APC core - these were major changes but not
breaking ones.
Breaking changes need significant notice as Levi points out.
So, about that Ternary operator?
My understanding is that major releases are the only ones allowed to have
breaking changes. Correcting the ternary operator to work like it does in
all other languages is a small example.
I don't think it's a good idea to turn this thread into a list of every
possible change we might want in PHP 8, but there is a general point to
be made here: the rule is that if you have a clear breaking change, it
is definitely not allowed in a minor release; not that it automatically
will be allowed in a major release.
Even a major release should maintain some compatibility - in particular,
it should be possible to write code that runs correctly on both the
previous and new versions. For instance: removing the old way of doing
something because a new way is already available, or making something an
error that was previously an avoidable warning.
In this example, changing the associativity directly would mean the same
code would run in both versions, but with different results, and that is
going to cause a lot of headaches. On the other hand, making it
non-associative, so that it was an error to write ambiguous code,
would probably save a lot of headaches.
Again, this feels less of a hardship if we plan major versions further
ahead: we might pencil in the new behaviour for 9.0, and be able to put
a date on that.
Regards,
--
Rowan Collins
[IMSoP]
1.) Old code breaks during minor updates. We upgraded to 7.0 AFTER 7.1 was
released, because we had already made major updates to upgrade to 7.0, and
7.1 introduced a few things that would have broken our code - we didn't
have time to fix those by that point. "Throw on passing too few function
arguments" would actually break more stuff in our legacy code than all of
the 7.0 changes combined.I agree. It was a bad decision on our part to do it in 7.1 - this bit a
lot of users.
IIRC, one of the arguments given at the time was "we don't know when 8.0
will be, so we might have to wait for a long time". I never liked that
argument, because it sounds like the arrival of a major release is
entirely out of our hands, when in fact the opposite is true.
My argument then, as now, was that we should plan further ahead when
each major release will be, and build up a list of things that will be
in it. If anything, I think we should bump the major version number
more often; if after 3 years we have 10 things like the too_few_args
RFC, get them implemented, bump the version number, and move forward.
On reflection, I think maybe that phrasing reveals a difference in
viewpoint: a lot of people talk about "a major release", which implies
there's something big and exciting, rather than just a number. I think
of it more like the marks on a ruler: centimetres are not more exciting
than millimetres, but they are less frequent, and have some significance.
It's tough enough for me to make a case for upgrading using the "increase performance" and "new
features" argument. There is no way I'd get the go-ahead to do an upgrade
that would just make additional features deprecated.
In an ideal world, there would be no reason not to upgrade to the next
minor version, because you would know that your code ran on "7.x", so
would just install the latest 7.x when it came out. I know reality is
never quite that simple, but I think we can get pretty close with a bit
of discipline and planning.
Regards,
--
Rowan Collins
[IMSoP]
-----Original Message-----
From: Levi Morrison [mailto:levim@php.net]
Sent: Sunday, June 24, 2018 5:31 PM
To: Zeev Suraski zeev@zend.com
Cc: internals internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 8 next?The trigger for a major release has always been very substantial
improvements/changes to the language, which I believe JIT, FFI and potentially
async squarely fit into (and I'll explain why I think that separately later this
week). This is true for PHP 3, 4, 5 and 7 (even though 3 and 5 did introduce
inherent compatibility breakages as a part of its new functionality).My position stands: I strongly object. If we rush to PHP 8 then it will be at
least 4-5 more years before we have another chance for breakages in PHP 9. We
can add features yearly.
Fair enough, your position is obviously entirely up to you - I just wanted to point out that having pushing a major version was never about breaking things - it was about delivering major new capabilities or performance to users - with the ability to break things as a side effect. I don't think I've ever seen nor delivered a PHP 7 presentation that included statements like "I can't wait to show you all the different things we broke in this new major version!!!" - this isn't what major versions are about.
I should also add that my position also stands - there's nothing that spectacular about breaking things, and for me at least, the celebration of being able to break things and the yearn to break more things before 4-5 years pass by is awkward. If we could bring major value with the users being able to just upgrade without an intense code audit/refactoring cycles, it's a feature - not a bug as far as I'm concerned.
That said - it's OK that we break things if the value of breaking them far outweighs the cost of fixing the consequences of the breakage - and by that I mean a more prolonged upgrade cycle and a certain degree of user angst.
Zeev
My position stands: I strongly object. If we rush to PHP 8 then it
will be at
least 4-5 more years before we have another chance for breakages in PHP 9. We
can add features yearly.
Fair enough, your position is obviously entirely up to you - I just wanted to point out that having pushing a major version was never about breaking things - it was about delivering major new capabilities or performance to users - with the ability to break things as a side effect. I don't think I've ever seen nor delivered a PHP 7 presentation that included statements like "I can't wait to show you all the different things we broke in this new major version!!!" - this isn't what major versions are about.I should also add that my position also stands - there's nothing that spectacular about breaking things, and for me at least, the celebration of being able to break things and the yearn to break more things before 4-5 years pass by is awkward. If we could bring major value with the users being able to just upgrade without an intense code audit/refactoring cycles, it's a feature - not a bug as far as I'm concerned.
That said - it's OK that we break things if the value of breaking them far outweighs the cost of fixing the consequences of the breakage - and by that I mean a more prolonged upgrade cycle and a certain degree of user angst.
I'd like to add to that : from the past 15 years we've seen that most
Linux distributions didn't really seem to care much about keeping up
with PHP versions, seemingly "because it's all PHP 5" (they didn't care
much about the major difference between 5.2, 5.3, 5.4 and beyond).
Ever since PHP 7 was released, there's been a lot more activity on their
end to get their distribution released either with PHP 7( even .1/.2),
or add PHP 7.x to an additional repo they support.
From that perspective, having a major version makes a lot of sense in
keeping the momentum going from the system engineering end of things,
ensuring they continuously keep an eye on what the latest version of PHP is.
Just my 2 cents as a non-core contributor.
Wim
Neither JIT nor FFI require backwards compatibility breaks in
language. I don't think either of those particular features would
substantially break the C API either. If these are the motivations for
PHP 8 then I strongly object.
Personally, I think that the big jump in performance that JIT warrants
is enough to justify a major version change, and it makes for a strong
selling point, even if there are no BC breaks
--
Mark Baker
|. \ -3
|J/ PHP |
|| | __ |
|| |m| |m|
I LOVE PHP
Hi internals,
Based on some recent conversations, I'm getting the impression that after
PHP 7.3, we might want to go for PHP 8 next.I'd like to discuss and possibility decide this now, as that would make PHP
7.3 the last chance to get in deprecations.
I think this is an appropriate place to discuss these potential
deprecations. What ones do you specifically have in mind?