Bump PHP requirement to 7.1 #6425
Comments
|
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 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. |
|
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" ***@***.***> 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
<#6425 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAJakNMYA_Es-eY59c6K5nfxXllKHEKDks5r3XodgaJpZM4NRtex>
.
|
|
Thanks for the clarification.
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
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. :( |
|
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" ***@***.***> 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
<#6425 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAJakIOG6rlW7XomE1SE-kFBpgus3licks5r3ZjxgaJpZM4NRtex>
.
|
|
@guilhermeblanco you had some thoughts to share here, what do you think about the suggestion? |
|
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. |
|
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. On the other hand, upgrade to 7.0 and then again to 7.1 sounds like a waste of effort... |
I start to think that the problem is not on our side. |
There won't be a 2.7: 2.6 is the last 2.x |
|
@Ocramius I suggested to have a 2.7. |
|
@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. |
|
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" <notifications@github.com> 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
<#6425 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAJakKvjT0pqnQR8TkVH6ZTQb68d_unAks5r3xx2gaJpZM4NRtex>
.
|
|
@Ocramius got it... so we'll require 7.1 on |
|
From my PoV, Doctrine is "good enough" in |
@Ocramius I'm confused now... does it mean that you want to bump the requirement on |
|
@lcobucci yes - no changes in 2.7 besides |
|
@Ocramius @guilhermeblanco alright, will send a PR to bump the requirement on Thanks 😉 |
|
@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... =) |
|
@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) |
|
@guilhermeblanco just so you know, on PHPDay 2017 IT @Ocramius and I decided to do the following:
|
|
Damn, with the object typehint RFC being accepted, I really feel like ORM 3.0 needs PHP 7.2... 😕 |
|
Agree, but let's wait for it first: it'sa long way ahead and the decision
will still be possible
…On 24 May 2017 23:08, "Michael Moravec" ***@***.***> 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
<#6425 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAJakA07rWBv_BnROKsSsVK2O46s-djAks5r9JxEgaJpZM4NRtex>
.
|
Require PHP 7 Related to doctrine/orm#6425
In fact, I would love if we could have
masteralways 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.5andv2.6.x-devnot 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:
masteronlyv2.6tov2.7.x-dev(basically more L2C improvements)v2.6.0and stop the active support onv2.5v2.7.x-devP.S.: HHVM concerns should be addressed in #6424
The text was updated successfully, but these errors were encountered: