Everything

php

PHP 8 next?

php.internals

Nikita Popov

8 years ago

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

Sara Golemon

8 years ago

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.

-Sara

Zeev Suraski

8 years ago

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

Alice Wonder

8 years ago

On 06/23/2018 03:11 PM, Zeev Suraski wrote:

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

Michael Morris

8 years ago

On Sat, Jun 23, 2018 at 6:39 PM Alice Wonder <alice@librelamp.com> wrote:

> On 06/23/2018 03:11 PM, Zeev Suraski wrote:
> >
> >
> >> -----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.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> 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???

Dustin Wheeler

8 years ago

Hello,

> On Jun 23, 2018, at 6:38 PM, Alice Wonder <alice@librelamp.com> wrote:
>
>> On 06/23/2018 03:11 PM, Zeev Suraski wrote:
>>
>> 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

Sara Golemon

8 years ago

On Sat, Jun 23, 2018 at 5:11 PM, Zeev Suraski <zeev@zend.com> wrote:

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

Levi Morrison

8 years ago

On Sat, Jun 23, 2018 at 4:11 PM Zeev Suraski <zeev@zend.com> wrote:

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

Kalle Sommer Nielsen

8 years ago

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

Zeev Suraski

8 years ago

> 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

Levi Morrison

8 years ago

On Sun, Jun 24, 2018 at 12:47 AM Zeev Suraski <zeev@zend.com> wrote:

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

Rowan Collins

8 years ago

On 24 June 2018 15:31:18 BST, Levi Morrison <levim@php.net> wrote:

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

Christoph Becker

8 years ago

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

Levi Morrison

8 years ago

On Sun, Jun 24, 2018 at 11:24 AM Rowan Collins <rowan.collins@gmail.com> wrote:

>
> On 24 June 2018 15:31:18 BST, Levi Morrison <levim@php.net> wrote:
> >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.

Rowan Collins

8 years ago

Hi Levi,

On 24 June 2018 22:26:24 BST, Levi Morrison <levim@php.net> wrote:

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

Mark Baker

8 years ago

On 24/06/2018 18:23, Rowan Collins wrote:

> 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

Chase Peeler

8 years ago

On Mon, Jun 25, 2018 at 1:16 PM Mark Baker <mark@lange.demon.co.uk> wrote:

> On 24/06/2018 18:23, Rowan Collins wrote:
> > 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
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.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

Zeev Suraski

8 years ago

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.

Zeev

Zeev Suraski

8 years ago

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

Wim Godden

8 years ago

On 24/06/2018 22:09, Zeev Suraski wrote:

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

Mark Baker

8 years ago

On 24/06/2018 01:58, Levi Morrison wrote:

> 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

Levi Morrison

8 years ago

On Sat, Jun 23, 2018 at 3:23 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

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