Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] PHP 8 next?

Posted by Nikita Popov 
Nikita Popov
[PHP-DEV] PHP 8 next?
June 23, 2018 11:30PM
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
Re: [PHP-DEV] PHP 8 next?
June 24, 2018 12:10AM
On Sat, Jun 23, 2018 at 4:22 PM, Nikita Popov <[email protected]> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Zeev Suraski
RE: [PHP-DEV] PHP 8 next?
June 24, 2018 12:20AM
> -----Original Message-----
> From: php@golemon.com [mailto:[email protected]] On Behalf Of Sara
> Golemon
> Sent: Sunday, June 24, 2018 1:07 AM
> To: Nikita Popov <[email protected]>
> Cc: PHP internals <[email protected]>
> Subject: Re: [PHP-DEV] PHP 8 next?
>
> On Sat, Jun 23, 2018 at 4:22 PM, Nikita Popov <[email protected]> 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
Re: [PHP-DEV] PHP 8 next?
June 24, 2018 12:50AM
On 06/23/2018 03:11 PM, Zeev Suraski wrote:
>
>
>> -----Original Message-----
>> From: php@golemon.com [mailto:[email protected]] On Behalf Of Sara
>> Golemon
>> Sent: Sunday, June 24, 2018 1:07 AM
>> To: Nikita Popov <[email protected]>
>> Cc: PHP internals <[email protected]>
>> Subject: Re: [PHP-DEV] PHP 8 next?
>>
>> On Sat, Jun 23, 2018 at 4:22 PM, Nikita Popov <[email protected]> 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/unsub.php
Michael Morris
Re: [PHP-DEV] PHP 8 next?
June 24, 2018 01:00AM
On Sat, Jun 23, 2018 at 6:39 PM Alice Wonder <[email protected]> wrote:

> On 06/23/2018 03:11 PM, Zeev Suraski wrote:
> >
> >
> >> -----Original Message-----
> >> From: php@golemon.com [mailto:[email protected]] On Behalf Of Sara
> >> Golemon
> >> Sent: Sunday, June 24, 2018 1:07 AM
> >> To: Nikita Popov <[email protected]>
> >> Cc: PHP internals <[email protected]>
> >> Subject: Re: [PHP-DEV] PHP 8 next?
> >>
> >> On Sat, Jun 23, 2018 at 4:22 PM, Nikita Popov <[email protected]>
> 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???

> http://www.php.net/unsub.php
>
>
Dustin Wheeler
Re: [PHP-DEV] PHP 8 next?
June 24, 2018 01:20AM
Hello,

> On Jun 23, 2018, at 6:38 PM, Alice Wonder <[email protected]> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sara Golemon
Re: [PHP-DEV] PHP 8 next?
June 24, 2018 02:10AM
On Sat, Jun 23, 2018 at 5:11 PM, Zeev Suraski <[email protected]> wrote:
>> On Sat, Jun 23, 2018 at 4:22 PM, Nikita Popov <[email protected]> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Levi Morrison
Re: [PHP-DEV] PHP 8 next?
June 24, 2018 03:10AM
On Sat, Jun 23, 2018 at 4:11 PM Zeev Suraski <[email protected]> wrote:
>
>
>
> > -----Original Message-----
> > From: php@golemon.com [mailto:[email protected]] On Behalf Of Sara
> > Golemon
> > Sent: Sunday, June 24, 2018 1:07 AM
> > To: Nikita Popov <[email protected]>
> > Cc: PHP internals <[email protected]>
> > Subject: Re: [PHP-DEV] PHP 8 next?
> >
> > On Sat, Jun 23, 2018 at 4:22 PM, Nikita Popov <[email protected]> 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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Kalle Sommer Nielsen
Re: [PHP-DEV] PHP 8 next?
June 24, 2018 03:30AM
Hi

Den søn. 24. jun. 2018 kl. 02.59 skrev Levi Morrison <[email protected]>:
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Levi Morrison
Re: [PHP-DEV] PHP 8 next?
June 24, 2018 04:50AM
On Sat, Jun 23, 2018 at 3:23 PM Nikita Popov <[email protected]> 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?

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Zeev Suraski
RE: [PHP-DEV] PHP 8 next?
June 24, 2018 08:50AM
> 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
Re: [PHP-DEV] PHP 8 next?
June 24, 2018 04:40PM
On Sun, Jun 24, 2018 at 12:47 AM Zeev Suraski <[email protected]> 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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Rowan Collins
Re: [PHP-DEV] PHP 8 next?
June 24, 2018 07:30PM
On 24 June 2018 15:31:18 BST, Levi Morrison <[email protected]> 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]
Zeev Suraski
RE: [PHP-DEV] PHP 8 next?
June 24, 2018 10:20PM
> -----Original Message-----
> From: Levi Morrison [mailto:[email protected]]
> Sent: Sunday, June 24, 2018 5:31 PM
> To: Zeev Suraski <[email protected]>
> Cc: internals <[email protected]>
> 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
Re: [PHP-DEV] PHP 8 next?
June 24, 2018 10:30PM
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



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christoph M. Becker
Re: [PHP-DEV] PHP 8 next?
June 24, 2018 10:40PM
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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Levi Morrison
Re: [PHP-DEV] PHP 8 next?
June 24, 2018 11:30PM
On Sun, Jun 24, 2018 at 11:24 AM Rowan Collins <[email protected]> wrote:
>
> On 24 June 2018 15:31:18 BST, Levi Morrison <[email protected]> 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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Rowan Collins
Re: [PHP-DEV] PHP 8 next?
June 25, 2018 04:00PM
Hi Levi,

On 24 June 2018 22:26:24 BST, Levi Morrison <[email protected]> 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]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Mark Baker
Re: [PHP-DEV] PHP 8 next?
June 25, 2018 07:20PM
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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Mark Baker
Re: [PHP-DEV] PHP 8 next?
June 25, 2018 07:20PM
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
Chase Peeler
Re: [PHP-DEV] PHP 8 next?
June 25, 2018 07:50PM
On Mon, Jun 25, 2018 at 1:16 PM Mark Baker <[email protected]> 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
Re: [PHP-DEV] PHP 8 next?
June 25, 2018 09:00PM
On Mon, Jun 25, 2018 at 8:40 PM Chase Peeler <[email protected]l.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
Michael Morris
Re: [PHP-DEV] PHP 8 next?
June 25, 2018 09:40PM
On Mon, Jun 25, 2018 at 2:55 PM Zeev Suraski <[email protected]> wrote:

> On Mon, Jun 25, 2018 at 8:40 PM Chase Peeler <[email protected]>
> 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.

>
>
Rowan Collins
Re: [PHP-DEV] PHP 8 next?
June 25, 2018 10:50PM
On 25/06/2018 19:54, Zeev Suraski wrote:
> On Mon, Jun 25, 2018 at 8:40 PM Chase Peeler <[email protected]> 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.

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]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Rowan Collins
Re: [PHP-DEV] PHP 8 next?
June 25, 2018 11:10PM
On 25/06/2018 20:34, Michael Morris wrote:
> 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]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login