Re: [PHP-DEV] PHP 8 next?

[Rowan Collins]

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

Re: [PHP-DEV] PHP 8 next?

[Rowan Collins]

On 25/06/2018 19:54, Zeev Suraski wrote:

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

Re: [PHP-DEV] PHP 8 next?

[Michael Morris]

On Mon, Jun 25, 2018 at 2:55 PM Zeev Suraski  wrote:

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

>
>

Re: [PHP-DEV] PHP 8 next?

[Zeev Suraski]

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

Re: [PHP-DEV] PHP 8 next?

[Chase Peeler]

On Mon, Jun 25, 2018 at 1:16 PM Mark Baker  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
chasepee...@gmail.com

Re: [PHP-DEV] PHP 8 next?

[Mark Baker]

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

Re: [PHP-DEV] PHP 8 next?

[Mark Baker]

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

Re: [PHP-DEV] PHP 8 next?

[Rowan Collins]

Hi Levi,

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

Re: [PHP-DEV] PHP 8 next?

[Levi Morrison]

On Sun, Jun 24, 2018 at 11:24 AM Rowan Collins  wrote:
>
> On 24 June 2018 15:31:18 BST, Levi Morrison  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

Re: [PHP-DEV] PHP 8 next?

[Christoph M. Becker]

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] 

-- 
Christoph M. Becker


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 8 next?

[Wim Godden]

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

RE: [PHP-DEV] PHP 8 next?

[Zeev Suraski]

> -Original Message-
> From: Levi Morrison [mailto:le...@php.net]
> Sent: Sunday, June 24, 2018 5:31 PM
> To: Zeev Suraski 
> Cc: internals 
> 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

Re: [PHP-DEV] PHP 8 next?

[Rowan Collins]

On 24 June 2018 15:31:18 BST, Levi Morrison  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]

Re: [PHP-DEV] PHP 8 next?

[Levi Morrison]

On Sun, Jun 24, 2018 at 12:47 AM Zeev Suraski  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

RE: [PHP-DEV] PHP 8 next?

[Zeev Suraski]

> 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

Re: [PHP-DEV] PHP 8 next?

[Levi Morrison]

On Sat, Jun 23, 2018 at 3:23 PM Nikita Popov  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

Re: [PHP-DEV] PHP 8 next?

[Kalle Sommer Nielsen]

Hi

Den søn. 24. jun. 2018 kl. 02.59 skrev Levi Morrison :
> 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
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 8 next?

[Levi Morrison]

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

Re: [PHP-DEV] PHP 8 next?

[Sara Golemon]

On Sat, Jun 23, 2018 at 5:11 PM, Zeev Suraski  wrote:
>> On Sat, Jun 23, 2018 at 4:22 PM, Nikita Popov  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

Re: [PHP-DEV] PHP 8 next?

[Dustin Wheeler]

Hello, 

> On Jun 23, 2018, at 6:38 PM, Alice Wonder  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

Re: [PHP-DEV] PHP 8 next?

[Michael Morris]

On Sat, Jun 23, 2018 at 6:39 PM Alice Wonder  wrote:

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

Re: [PHP-DEV] PHP 8 next?

[Alice Wonder]

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




-Original Message-
From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara
Golemon
Sent: Sunday, June 24, 2018 1:07 AM
To: Nikita Popov 
Cc: PHP internals 
Subject: Re: [PHP-DEV] PHP 8 next?

On Sat, Jun 23, 2018 at 4:22 PM, Nikita Popov  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

RE: [PHP-DEV] PHP 8 next?

[Zeev Suraski]

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

Re: [PHP-DEV] PHP 8 next?

[Sara Golemon]

On Sat, Jun 23, 2018 at 4:22 PM, Nikita Popov  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

[PHP-DEV] PHP 8 next?

[Nikita Popov]

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