Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] Re: PHP 2^3

Posted by Christoph M. Becker 
Christoph M. Becker
[PHP-DEV] Re: PHP 2^3
June 25, 2018 05:00PM
On 25.06.2018 at 14:30, Zeev Suraski wrote:

> What this list is - a collection of directions around which we've performed varying amounts of research (some of them quite a lot, like JIT), that I think is strong grounds for us to start discussing a PHP 8 timeline, and making PHP 7.3 the last feature release in the PHP 7.x family. If we had to come up with an educated guess as to when PHP 8 could be ready to be released based on the abovementioned featureset, we're probably talking about 2-2.5yrs away (i.e. mid/late 2020). We can also consider having a very slim PHP 7.4 release sometime in 2019 that wouldn't add any functionality, but that would give us an opportunity to deprecate anything that we missed in 7.3 that truly requires deprecation - while still allowing folks to prepare for 8.0 ahead of time.

Why not stick with our yearly release cycle, and ship 7.4.0 in Dec 2019
and 8.0.0 in Dec 2020?

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Zeev Suraski
Re: [PHP-DEV] Re: PHP 2^3
June 25, 2018 05:10PM
On Mon, Jun 25, 2018 at 5:57 PM Christoph M. Becker <[email protected]>
wrote:

> On 25.06.2018 at 14:30, Zeev Suraski wrote:
>
> > What this list is - a collection of directions around which we've
> performed varying amounts of research (some of them quite a lot, like JIT),
> that I think is strong grounds for us to start discussing a PHP 8 timeline,
> and making PHP 7.3 the last feature release in the PHP 7.x family. If we
> had to come up with an educated guess as to when PHP 8 could be ready to be
> released based on the abovementioned featureset, we're probably talking
> about 2-2.5yrs away (i.e. mid/late 2020). We can also consider having a
> very slim PHP 7.4 release sometime in 2019 that wouldn't add any
> functionality, but that would give us an opportunity to deprecate anything
> that we missed in 7.3 that truly requires deprecation - while still
> allowing folks to prepare for 8.0 ahead of time.
>
> Why not stick with our yearly release cycle, and ship 7.4.0 in Dec 2019
> and 8.0.0 in Dec 2020?
>

We could and I think we should, but I don't think 7.4 should be a feature
release - but rather another release where we can deprecate things without
rushing them into 7.3, and at the same time provide people with a smoother
upgrade path to 8.0 (even though as you know, I'm not the biggest fan of
compatibility breakages...). We've never been successful at working on two
active-development branches at the same time, and with the resource levels
we have - I don't think it's practical.

To be perfectly honest, I don't think our userbase for the most part is
actually consuming the feature releases at nearly the frequency that we're
producing them. It's a healthy release cycle, but I really don't think
that there would be any meaningful downside to have two years between the
last feature-release 7.x and 8.0.

Zeev
Jakub Zelenka
Re: [PHP-DEV] Re: PHP 2^3
June 27, 2018 03:10PM
On Mon, Jun 25, 2018 at 4:03 PM, Zeev Suraski <[email protected]> wrote:

> On Mon, Jun 25, 2018 at 5:57 PM Christoph M. Becker <[email protected]>
> wrote:
>
> > On 25.06.2018 at 14:30, Zeev Suraski wrote:
> >
> > > What this list is - a collection of directions around which we've
> > performed varying amounts of research (some of them quite a lot, like
> JIT),
> > that I think is strong grounds for us to start discussing a PHP 8
> timeline,
> > and making PHP 7.3 the last feature release in the PHP 7.x family. If we
> > had to come up with an educated guess as to when PHP 8 could be ready to
> be
> > released based on the abovementioned featureset, we're probably talking
> > about 2-2.5yrs away (i.e. mid/late 2020). We can also consider having a
> > very slim PHP 7.4 release sometime in 2019 that wouldn't add any
> > functionality, but that would give us an opportunity to deprecate
> anything
> > that we missed in 7.3 that truly requires deprecation - while still
> > allowing folks to prepare for 8.0 ahead of time.
> >
> > Why not stick with our yearly release cycle, and ship 7.4.0 in Dec 2019
> > and 8.0.0 in Dec 2020?
> >
>
> We could and I think we should, but I don't think 7.4 should be a feature
> release - but rather another release where we can deprecate things without
> rushing them into 7.3, and at the same time provide people with a smoother
> upgrade path to 8.0 (even though as you know, I'm not the biggest fan of
> compatibility breakages...). We've never been successful at working on two
> active-development branches at the same time, and with the resource levels
> we have - I don't think it's practical.
>
>
I think it makes sense for big engine changes that you described but I
don't think this should be the case for features in core extensions and
SAPI's. The thing is that some of us are not going to work on those big
changes for various reasons. Personally I work mainly on fpm, openssl as
well as some other stuff and just don't have time to do anything else atm.
My features are not really so big that they should wait 2 years. The thing
is that this type of changes won't usually conflict with engine changes so
there should be no reason to delay it.

So I think it would be good idea to lock the engine (possibly create a
special branch for all the new changes into it) and release 7.4 and maybe
7.5 (in case 8.0 is not ready in time) with just deprecations and features
in extensions and SAPI's.

Cheers

Jakub
Christoph M. Becker
Re: [PHP-DEV] Re: PHP 2^3
June 27, 2018 03:20PM
On 27.06.2018 at 15:00, Jakub Zelenka wrote:

> I think it makes sense for big engine changes that you described but I
> don't think this should be the case for features in core extensions and
> SAPI's. The thing is that some of us are not going to work on those big
> changes for various reasons. Personally I work mainly on fpm, openssl as
> well as some other stuff and just don't have time to do anything else atm.
> My features are not really so big that they should wait 2 years. The thing
> is that this type of changes won't usually conflict with engine changes so
> there should be no reason to delay it.
>
> So I think it would be good idea to lock the engine (possibly create a
> special branch for all the new changes into it) and release 7.4 and maybe
> 7.5 (in case 8.0 is not ready in time) with just deprecations and features
> in extensions and SAPI's.

This was my first thought as well, but considering the changes that PHP
7 required for *all* extensions, working on 7.4 and 8.0 simultaneously
may easily lead to hard to resolve merge conflicts, and even to subtle
breakages.

However, instead of locking 7.4 for everything but deprecations in
advance, we may consider to decide on a case-by-case basis if a new
feature should target 7.4 or 8.0.

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Jakub Zelenka
Re: [PHP-DEV] Re: PHP 2^3
June 27, 2018 04:00PM
On Wed, Jun 27, 2018 at 2:10 PM, Christoph M. Becker <[email protected]>
wrote:

> On 27.06.2018 at 15:00, Jakub Zelenka wrote:
>
> > I think it makes sense for big engine changes that you described but I
> > don't think this should be the case for features in core extensions and
> > SAPI's. The thing is that some of us are not going to work on those big
> > changes for various reasons. Personally I work mainly on fpm, openssl as
> > well as some other stuff and just don't have time to do anything else
> atm.
> > My features are not really so big that they should wait 2 years. The
> thing
> > is that this type of changes won't usually conflict with engine changes
> so
> > there should be no reason to delay it.
> >
> > So I think it would be good idea to lock the engine (possibly create a
> > special branch for all the new changes into it) and release 7.4 and maybe
> > 7.5 (in case 8.0 is not ready in time) with just deprecations and
> features
> > in extensions and SAPI's.
>
> This was my first thought as well, but considering the changes that PHP
> 7 required for *all* extensions, working on 7.4 and 8.0 simultaneously
> may easily lead to hard to resolve merge conflicts, and even to subtle
> breakages.
>
>
Well it was mainly about changing the zval but I guess it won't be the same
for 8.0 unless there are some plans for big breaking changes. It would
probably make sense to reconsider in that case but if the ABI stays the
same or the changes are minimal, then it shouldn't block new features to
the extensions IMO. In terms of SAPI's like FPM, it's a bit different as it
is mostly independent code and most of the features can be released without
any conflict even if the engine ABI changes considerably.

Cheers

Jakub
Sorry, only registered users may post in this forum.

Click here to login