search

silverstripe / silverstripe-framework

Silverstripe Framework, the MVC framework that powers Silverstripe CMS
https://www.silverstripe.org
BSD 3-Clause "New" or "Revised" License
721 stars 821 forks source link

Agree on end date for PHP 5.x support for 3.x and 4.x lines #8556

Closed chillu closed 5 years ago

chillu commented 6 years ago

PHP is going EOL end of the year: http://php.net/supported-versions.php. Our server requirements doc states "PHP 5.6 and PHP 7.x" support. As an open source project, we should make clear statements about our support. I would argue that it's not a semver violation to drop language support for a language version that's EOL, but that's up for discussion. Going PHP 7 only will have some advantages which I'm sure someone will be able to list here ;)

Minor releases are supported for 18 months now (see announcement), so technically that's your grace period for PHP 5.x support. It's debatable if "supported release" includes support on EOL language versions. I'd argue that those two are separate. It's unclear if we can even run CI on PHP 5.x for this long (depending on Travis support).

Note: For some platforms associated with the SilverStripe projects, commitments have been made by SilverStripe Ltd. about grace periods (https://www.cwp.govt.nz/updates/news/php-7-1-upgrade/).

Drupal has announced back in Jan 2018 that Drupal 8.x will remove PHP 5.x support in March 2019.

/cc @silverstripe/core-team

kinglozzer commented 6 years ago

I don’t really see this affecting the 3.x release line, as providing PHP 5 support is really no extra effort at all given there’s no feature development on that release line now. We could exclude old PHP versions for the sake of it, but people will just --ignore-platform-reqs if we do that anyway, so I don’t see any advantage of doing so when the code would be PHP 5.x compatible anyway.

I agree that we could drop EOL PHP versions for 4.x, presumably that’d be done in a minor release?

sminnee commented 6 years ago

We "soft-dropped" support for PHP 5.3 due to Travis deprecating its test environments - composer still allows PHP 5.3 but we're no longer testing fixes against it. I'd be inclined to take the same approach for PHP 5.4, 5.5, 5.6.

Given that the practical benefit of semver is to make upgrades safer, I'm not sure how forcing a PHP-upgrade in a minor release is in keeping with any use definition of semver. Deprecating a PHP version might be a good idea, though?

I'd support deprecating PHP support from Dec 31, but IMO we'd need a really good reason to do more than that.

maxime-rainville commented 6 years ago

It makes me sad, but I'm going to agree with Sam. Unless there's a reason outside of our control that makes it impractical to keep supporting a specific version of PHP that we're committed to supporting, we probably should keep supporting it until the next major release.

What would "deprecating" a PHP version mean in practice, thought? In the context of our own code, we can remove all references to the deprecated code, alias the deprecated API to newer ones, throw warnings, etc. We can't really do any of those things with the PHP version, can we?

sminnee commented 6 years ago

It makes me sad, but I'm going to agree with Sam.

I need that on a poster or something.

chillu commented 6 years ago

We "soft-dropped" support for PHP 5.3 due to Travis deprecating its test environments - composer still allows PHP 5.3 but we're no longer testing fixes against it. I'd be inclined to take the same approach for PHP 5.4, 5.5, 5.6. I'd support deprecating PHP support from Dec 31, but IMO we'd need a really good reason to do more than that.

Yeah, I think that's the most viable path - if we reach that agreement, should we document this somewhere?

but IMO we'd need a really good reason to do more than that.

It would allow us to use more modern language constructs, particularly with so much focus on 4.x over 5.x in the next year. But that's a minor concern compared to the pain a hard drop would cause for devs stuck on PHP 5 (e.g. because sysadmin says no ™️).

We rely on Symfony 3.x, which supports PHP 5.5.9 or higher. The roadmap states it's supported until 2021, which means we're not forced to upgrade to Symfony 4.x in the SilverStripe 4.x release line. They have pretty strong backwards compat promises, so I'd be surprised if they drop PHP 5.x support in Symfony 3.x. Half of the internet relies on this stuff :D

There's some discussion about encryption APIs in core where some of the options are PHP 7.1+, but I don't think that's a strong driver.

dnsl48 commented 5 years ago

It feels like we may have to proactively support 5.6 until at least the EOL of Debian and Ubuntu LTS, which is April 2019.

I'm trying to figure out the impact of this and I see 3 affected parties:

People reading the documentation will see we claim supporting it and won't be expecting us to drop it in a patch release. Thus, if our support for it differs from its official lifetime, then I think we should clearly state so in the documentation and name the date when we drop it. Otherwise, it's gonna be giving the users false hopes.

What do you reckon if we drop our claims for supporting 5.6 in the documentation for >=4.4, but keep supporting it in <4.4 (by dropping from the documentation I'm not saying we should stop caring about it, but maybe at least we should stop claiming we are supporting it proactively)

robbieaverill commented 5 years ago

We've kind of done that for PHP 5.3 in SilverStripe 3, but that's another example where we still support it, we just don't have it in our Travis builds any more and to use it people would have to run their own installs because it's so far out of support now.

sminnee commented 5 years ago

My view would be that we deprecate the older PHP/MySQL/PostgreSQL/etc versions, rather than drop them. Minimally, this means:

Optionally, this means:

I would limit ourselves to deprecating 3rd party components that are EOLed by the principal maintainers of those components (so we deprecated PHP 5.6 when PHP says it's EOL, not when Debian LTS says its EOL).

We should apply this to Apache, MySQL, PostgreSQL, as well as PHP

dnsl48 commented 5 years ago

If we claim supporting it in the documentation we should clearly state until when we going to do so, otherwise people will have false assumptions. Should we explain in the docs that we're going to follow the Travis support for those?

Other questions I can think of

sminnee commented 5 years ago

If we claim supporting it in the documentation we should clearly state until when we going to do so, otherwise people will have false assumptions.

Support will last until SS5, otherwise we're breaking semver. But "deprecated" still means "supported"

sminnee commented 5 years ago

We should keep refusing PRs breaking PHP 5.6 while Travis supports PHP 5.6

Yeah this is the case. Based on our experience with Travis' support of PHP 5.3 it's reasonable to assume that PHP 5.6 will be supported for the 4.x lifetime.

dnsl48 commented 5 years ago

So, if I understand everything correctly, please confirm this fix for the documentation (#8647):

## Web server software requirements

 * PHP 7.1 and higher
   * 5.6 and 7.0 are supported, but deprecated.
     This means we do our best to support those,
     but we recommend you to upgrade.
   * Once PHP versions become [unsupported by the PHP Project](http://php.net/supported-versions.php),
     we drop support for those versions in the [next major release](/contributing/release-process).
     This means that PHP 5.6 support will be dropped in a SilverStripe 5.0 release.
maxime-rainville commented 5 years ago

I'm not sure we need to commit to specific PHP versions for future major release. E.g.: If we had released SS5 two month ago, we probably would have dropped PHP 5.6 and 7.0 support even if they're official supported until the end of the year.

I would just leave it at "we won't break old version of PHP in the current release". For future release I would like us to keep the flexibility of saying "sorry, we're not supporting this version of PHP who is about to go out of support any way".

dnsl48 commented 5 years ago

Are you suggesting we just name the list of supported versions for each release and leave the deprecation notes out of the documentation?

maxime-rainville commented 5 years ago

I would keep the point about 5.6 and 7.0 are supported, but .... I would remove the last point about Once PHP versions become[unsupported by the PHP ....

We don't know what our minimal PHP version will be in SS5. We know it won't support 5.6 or 7.0 and that's about it.

dnsl48 commented 5 years ago

Ok, I'm pushing this to #8647

chillu commented 5 years ago

We should apply this to Apache, MySQL, PostgreSQL, as well as PHP

@sminnee I'm not sure we're doing ourselves any favours with this "deprecated but supported" policy outside of PHP. There's a fairly clear case in PHP, but for MySQL and Postgres, I don't think we need to support versions like MySQL 5.5 which have been released 8 years ago, and are EOL this month. Let's continue the MySQL discussion over at https://github.com/silverstripe/silverstripe-framework/issues/8651. Having a generic policy is good, but any extra permutation we support slows down builds on everything we build on top of framework (70+ supported modules). It also limits our room for movement, for example implementing JSON fields in core. "deprecated but supported" is a hit we're taking with PHP 5.6 support, but I don't see the case for MySQL and Postgres.

sminnee commented 5 years ago

I’m okay with dropping, say, MySQL 5.5, but I think we should then basically admit that our lack of clarity on version support was a “bug in our docs” and, whatever database versions we say work now, we commit to for the rest of 4.x

dhensby commented 5 years ago

I would argue that it's not a semver violation to drop language support for a language version that's EOL, but that's up for discussion. Going PHP 7 only will have some advantages which I'm sure someone will be able to list here ;)

Agreed

dhensby commented 5 years ago

I think there's a general consensus here which is summed up as:

  1. Stop going out of our way to support 5.x and 7.0
  2. Don't block installation by bumping the min version in composer
  3. Keep tests suites running as long as possible to give assurance we aren't breaking unsupported PHP versions

On a side note, my opinion is that we can bump versions of PHP in minor releases as PHP should just be classed as a dependency like any other package we declare dependency on and we can bump those in minor releases as long as we don't break our API contracts in the process. This is something we could consider doing in the future if we come to an agreement on this point.

chillu commented 5 years ago

I’m okay with dropping, say, MySQL 5.5, but I think we should then basically admit that our lack of clarity on version support was a “bug in our docs” and, whatever database versions we say work now, we commit to for the rest of 4.x

My point is that by default, we shouldn't support system dependencies like Apache, PHP or MySQL beyond their own declared EOLs. We can make exceptions where that isn't practical (PHP 5.x).

chillu commented 5 years ago

So here's a curveball: @unclecheese raised that the webonyx/graphql-php library we're using in silverstripe/graphql has released 0.13.0 a few days ago, and it requires PHP 7.1+. This is a hard dependency on the CMS, since GraphQL is required to operate CMS UIs like AssetAdmin.

Given how young this module is, and how central it is to our overall product strategy, I'm having a hard time envisioning that we'll continue using the PHP 5.x compatible 0.12.0 version until the end of 2020 (when we move from "full support" to "limited support" in the 4.x release line).

Option A: Bump SS 4.x PHP requirements to PHP 7.1+ sometime in 2019 (months past the official EOL for PHP 5.x) - apply to next minor release, and keep current minor releases PHP 5.6+ compatible Option B: Fork module, patch to make PHP 5.x compatible, hope they don't introduce reliance on language features we can't replicate in PHP 5.x Option C: Stay on webonyx/graphql-php 0.12.0 until 2020 Option D: Create new major releases of GraphQL module with PHP 7.1+, but don't rely on them in SS 4.x. I don't think that's feasible, since the module development is driven by changes required to make CMS UIs work

My preference is Option A.

kinglozzer commented 5 years ago

I’d have no problem with Option A :)

sminnee commented 5 years ago

Perhaps we slate the removal of PHP 5.6 for 4.5 and preannounce it?

robbieaverill commented 5 years ago

I have no problem with option A either

maxime-rainville commented 5 years ago

Option A sounds reasonable.

Do we have much stats on how many people are using SS4 with PHP5? I can't imagine that it's a very common set up ... then again they were quite few that were complaining that the upgrader requires PHP 7.1, so what do I know.

ScopeyNZ commented 5 years ago

I'm always going to be for removing support for unsupported versions 🙂

chillu commented 5 years ago

So we have six core committers (@maxime-rainville @robbieaverill @sminnee @kinglozzer @chillu @ScopeyNZ) for Option A, which I take as agreement.

In terms of when we should do this, I'd rather say "next minor release after <date>" than pinning it on a specific minor release. That keeps our timing options a bit more open. My recommendation for would be 01/07/2019, which coincides with our quarterly CWP releases, and usually coincides with a minor core release. Given that EOL for our minor releases is preannounced at least six months in advance. Assuming we release 4.5 on 01/07/2019, we'd announce the EOL for 4.4 to 01/01/2020. This means you can stay on a supported 4.x release line which works with PHP 5.x until that date. which is a whole year longer than PHPs own EOL. Good enough, right?

sminnee commented 5 years ago

That seems good, but I'd suggest that we announce all of this (including the minimum 4.4 EOL) Dec/Jan so that people have a year's notice about having to upgrade PHP 5.6

chillu commented 5 years ago

Yeah working on the comms bits at the moment.

brynwhyman commented 5 years ago

@chillu: My recommendation for would be 01/07/2019, which coincides with our quarterly CWP releases, and usually coincides with a minor core release.

A quick note that the quarterly CWP release would be scheduled around 01/06/19, not July.

chillu commented 5 years ago

OK, blog post draft at https://docs.google.com/document/d/1qWPi-O-6_RLtTkZ-PfElf8JEchvhIy-_93NMOTQ8WHc/edit?usp=sharing. We haven't really discussed what happens with 3.x in this regard. Here's my proposal (extract from blog):

The SilverStripe 3.x release line is supported until 31/09/2020 (see our roadmap). The current 3.x release (3.7) is compatible up to PHP 7.2 (details). After ceasing support for PHP 5.6 in SilverStripe 4.x end of 2019, it will also be deprecated in SilverStripe 3.x. While we don’t intend to actively break support in this release line, PHP 5.6 specific testing will be on a best effort basis.

chillu commented 5 years ago

A quick note that the quarterly CWP release would be scheduled around 01/06/19, not July.

Thanks for clarifying this, I've ensured that the wording reflects that. Meaning in the likely case that we'll do a new minor release as part of this quarterly CWP release, that release (likely 4.5.0) would be the first where we don't have to support PHP 5.x.

In order to support this transition, the core team has decided to extend PHP 5.6 support in core and our supported modules for minor releases made before 01/06/2019. Since we’re committing to preannounce EOL on minor releases at least six months in advance, this effectively means PHP 5.6 support in supported 4.x releases until end of 2019. We will start creating new 4.x releases requiring PHP 7.x in mid 2019.

dhensby commented 5 years ago

Sorry for late reply, but I'm happy with option A too

chillu commented 5 years ago

Everyone happy with the wording for how we deal with 3.x above? Seems in the spirit of what Sam was suggesting earlier.

sminnee commented 5 years ago

Seems good to me

sminnee commented 5 years ago

@chillu what's outstanding on this? Looks like the blog post has gone out... anything more need to be done?

chillu commented 5 years ago

Yep, been announced. We need to change the server requirements once those dates actually kick in, but nothing left to do in the meantime. https://www.silverstripe.org/blog/our-plan-for-ending-php-5-6-support-in-silverstripe-4/

robbieaverill commented 5 years ago

I've made pull requests to update Travis configuration in all the core modules and recipes (see above), but will wait to do this for the CWP recipes and modules that will use SilverStripe 4.5.x-dev until we next start to assemble that release. Master of CWP kitchen sink is currently using SilverStripe 4.4.x-dev (as is CWP kitchen sink 2.3)

chillu commented 5 years ago

@robbieaverill Legend! Merged 'em all, apart from two where we have upstream failures which are on the verge of being fixed: https://github.com/silverstripe/silverstripe-assets/pull/278 and https://github.com/silverstripe/silverstripe-asset-admin/pull/945

ScopeyNZ commented 5 years ago

Whoops I merged asset-admin. What was the specific reason for that not being merged?

chillu commented 5 years ago

asset-admin has two failed tests in the 1 branch (https://travis-ci.org/silverstripe/silverstripe-asset-admin/jobs/543328181#L1577), and one failed test in the 1.4 branch (https://travis-ci.org/silverstripe/silverstripe-asset-admin/jobs/543338596#L1614). I think that was my reason for not merging, but it's unlikely that the PHP upgrade caused that.

chillu commented 5 years ago

FYI we're now able to create PHP 7 only core release (as of 1st of June, see https://www.silverstripe.org/blog/our-plan-for-ending-php-5-6-support-in-silverstripe-4/). That'll be 4.5.0, not 4.4.0, because those merges came in too late to hit that release.