Orm: Bump PHP requirement to 7.1

[lcobucci]

In fact, I would love if we could have master always requiring the latest PHP (stable) version.

That would have a very positive impact on the developer experience (of maintainers and contributors) since it allow us to use new PHP features, simplify the code and prevent weird type juggling issues. There's of course a big impact on the community adoption since not everybody keep their environment up to date (unfortunately) and we'll be restricting the audience of the latest versions.

Right now we have a big gap between v2.5 and v2.6.x-dev not only because of new features but also regarding bugs that couldn't be backported due to dependencies (L2C modifications and big refactorings that were made).

My suggestion is to:

1. Wrap up all the bugs we have that are easy to be solved and merge them in master only
2. Move the new features we planned for v2.6 to v2.7.x-dev (basically more L2C improvements)
3. Release v2.6.0 and stop the active support on v2.5
4. Require PHP 7.1 on v2.7.x-dev

P.S.: HHVM concerns should be addressed in #6424

[lemartin]

What does stopping _active_ support mean? Will there be no fixes whatsoever?

For people, like us, who deploy software into existing enterprise infrastructure and cannot require any PHP version beyond the one shipped with the distribution (either Debian or RHEL/CentOS in our case), this would mean, that we have to roll our own fork of v2.5.x for bug fixes, as the common denominator in PHP versions is 5.6 at the moment. I guess other people would to, as, based on the last statistics published by Seldaek of Nov. 2016, only 35% of packagist users are running PHP 7.0. And as always, there is no guarantee that the fixes on the forks will be upstreamed.

Anyways, I think all I do want to say is, dropping active support for the version targeting the general available and used PHP interpreter feels a bit eager.

[Ocramius]

Older versions will still get security fixes: we always did that. Bugfixes
only if worth it, and we rarely backport anyway, as we have limited time.
New software on new infrastructure, released software on fixed
infrastructure (current stable version at the time it was released). Even
on RHEL and ancient centos versions, having 7.1 support is trivial thanks
to the amazing work done by the future php RM, no excuses.

On 7 May 2017 10:00 a.m., "Martin Waßmann" [e-mail] wrote:

What does stopping active support mean? Will there be no fixes
whatsoever?

For people, like us, who deploy software into existing enterprise
infrastructure and cannot require any PHP version beyond the one shipped
with the distribution (either Debian or RHEL/CentOS in our case), this
would mean, that we have to roll our own fork of v2.5.x for bug fixes, as
the common denominator in PHP versions is 5.6 at the moment. I guess other
people would to, as, based on the last statistics
https://seld.be/notes/php-versions-stats-2016-2-edition published by
Seldaek of Nov. 2016, only 35% of packagist users are running PHP 7.0. And
as always, there is no guarantee that the fixes on the forks will be
upstreamed.

Anyways, I think all I do want to say is, dropping active support for the
version targeting the general available and used PHP interpreter feels a
bit eager.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/doctrine/doctrine2/issues/6425#issuecomment-299689134,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJakNMYA_Es-eY59c6K5nfxXllKHEKDks5r3XodgaJpZM4NRtex
.

[lemartin]

Thanks for the clarification.

Bugfixes only if worth it, and we rarely backport anyway, as we have limited time.

That is actually why I asked, what stopping active support means, as it is already limited Why not keep it this way? I'm sure if someone needs something fixed also in v2.5.x a PR would happily supplied. There is ofc the need to review it.

Even on RHEL and ancient centos versions, having 7.1 support is [...] no excuses.

On CentOS and RHEL there are SCLs with defined life cycles, I'm not aware of anything similar for Debian. Until the not even released Stretch gets a back-port for 7.1 there is no officially supported way. Currently developed software targeting Debian would require to support 5.6. Yes, there may be repositories providing new PHP versions for Debian, but none I am aware of are giving any guarantee on fixes or provide a life-cycle. Sorry for the digression. :(

[Ocramius]

At the end of the day, there is no guarantee on anything from us either
btw: that's why we have MIT as licence 😋

On 7 May 2017 12:12 p.m., "Martin Waßmann" [e-mail] wrote:

Thanks for the clarification.

Bugfixes only if worth it, and we rarely backport anyway, as we have
limited time.

That is actually why I asked, what stopping active support means, as it is
already limited Why not keep it this way? I'm sure if someone needs
something fixed also in v2.5.x a PR would happily supplied. There is ofc
the need to review it.

Even on RHEL and ancient centos versions, having 7.1 support is [...] no
excuses.

On CentOS and RHEL there are SCLs with defined life cycles, I'm not aware
of anything similar for Debian. Until the not even released Stretch gets a
back-port for 7.1 there is no officially supported way. Currently developed
software targeting Debian would require to support 5.6. Yes, there may be
repositories providing new PHP versions for Debian, but none I am aware of
are giving any guarantee on fixes or provide a life-cycle. Sorry for the
digression. :(

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/doctrine/doctrine2/issues/6425#issuecomment-299695414,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJakIOG6rlW7XomE1SE-kFBpgus3licks5r3ZjxgaJpZM4NRtex
.

[lcobucci]

@guilhermeblanco you had some thoughts to share here, what do you think about the suggestion?

[guilhermeblanco]

Yes, I do. I wouldn't recommend dropping PHP 7.0 support on 2.6. However, I think we're good to go with 2.7 as being PHP 7.1 only.

[Majkl578]

As already mentioned, Debian Stretch will default to PHP 7.0 for at least another 2 years... At least it'll be easier to install multiple versions thanks to co-installability, but still, most Linux admins will just refuse to install anything that is not in stable repository.
Btw. 7.0 was never backported to Jessie, it still has only 5.6.

On the other hand, upgrade to 7.0 and then again to 7.1 sounds like a waste of effort...

[Ocramius]

most Linux admins will just refuse to install anything that is not in stable repository.

I start to think that the problem is not on our side.

[Ocramius]

@guilhermeblanco

Yes, I do. I wouldn't recommend dropping PHP 7.0 support on 2.6. However, I think we're good to go with 2.7 as being PHP 7.1 only.

There won't be a 2.7: 2.6 is the last 2.x

[lcobucci]

@Ocramius I suggested to have a 2.7.

[Ocramius]

@lcobucci don't see value in it then - let's release 2.6, then 2.7 with deprecation notices only (simply mitigates migration to 3.x), and we close shop until 3.0 is out.

[mvrhov]

There is dotdeb for Debian, for Ubuntu there is a PPA from official maintainer.

[lcobucci]

@lcobucci don't see value in it then - let's release 2.6, then 2.7 with deprecation notices only (simply mitigates migration to 3.x), and we close shop until 3.0 is out.

@Ocramius So are we finishing the L2C stuff for this version or are we holding 2.6 release till we have it?

[Ocramius]

We hold it until it's done. I won't be able to sit down and do releases
until July anyway.

On 8 May 2017 3:45 p.m., "Luís Cobucci" [e-mail] wrote:

@lcobucci https://github.com/lcobucci don't see value in it then - let's
release 2.6, then 2.7 with deprecation notices only (simply mitigates
migration to 3.x), and we close shop until 3.0 is out.

So we're finishing the L2C stuff for this version or are we holding 2.6
release till we have it?

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/doctrine/doctrine2/issues/6425#issuecomment-299870890,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJakKvjT0pqnQR8TkVH6ZTQb68d_unAks5r3xx2gaJpZM4NRtex
.

[lcobucci]

@Ocramius got it... so we'll require 7.1 on develop which means that @guilhermeblanco can go crazy and add void and nullable everywhere 😂

[Ocramius]

From my PoV, Doctrine is "good enough" in 2.5 for all users complaining about lack of oldstable support, while we will catch gazillions of errors by just adding void, ? and iterable and so on to our type hints.

[lcobucci]

From my PoV, Doctrine is "good enough" in 2.5 for all users complaining about lack of oldstable support, while we will catch gazillions of errors by just adding void, ? and iterable and so on to our type hints.

@Ocramius I'm confused now... does it mean that you want to bump the requirement on 2.6?

[Ocramius]

@lcobucci yes - no changes in 2.7 besides @trigger_error() additions (or whatever the equivalent is)

[lcobucci]

@Ocramius @guilhermeblanco alright, will send a PR to bump the requirement on master this week and I'm closing this issue.

Thanks 😉

[guilhermeblanco]

@Ocramius I don't see bumping to 7.1 as a good option if it does work for 7.0 and we're almost ready to release. We could stick with 7.0 since it's the last minor on 2.x without any problems.

On 3.x it's already 7.1... =)

[lcobucci]

@guilhermeblanco the thing is that we're not "almost ready to release" there are still things to be created (and some are not small nor trivial)

[lcobucci]

@guilhermeblanco just so you know, on PHPDay 2017 IT @Ocramius and I decided to do the following:

1. Wrap up all the bugs we have that are easy to be solved and merge them in master only
2. Move the new features we planned for v2.6 to v2.7.x-dev (basically more L2C improvements)
3. Require PHP 7.1 on v2.6.x-dev
4. Release v2.6.0 and stop the active support on v2.5
5. Have v2.8 as the last v2.x version with deprecation notes ONLY

[Majkl578]

Damn, with the object typehint RFC being accepted, I really feel like ORM 3.0 _needs_ PHP 7.2... 😕

[Ocramius]

Agree, but let's wait for it first: it's​a long way ahead and the decision
will still be possible

On 24 May 2017 23:08, "Michael Moravec" [e-mail] wrote:

Damn, with the object typehint RFC
https://wiki.php.net/rfc/object-typehint being accepted, I really feel
like ORM 3.0 needs PHP 7.2... 😕

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/doctrine/doctrine2/issues/6425#issuecomment-303852233,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJakA07rWBv_BnROKsSsVK2O46s-djAks5r9JxEgaJpZM4NRtex
.