RFC: Adopt an official Symfony support policy

[maxime-rainville]

Our official support policy for Symfony dependencies is kind of a mess:

• Support for different Symfony libraries will very across modules and is inconsistent
• We still ostensibly support ancient EOL version while not supporting more recent supported version
• We don't take into consideration Symfony's support timeline

We also need to consider that many Silverstripe CMS project will also use Symfony for their own purpose and that there's value in supporting multiple release line simultaneously.

Proposed policy

Silverstripe CMS modules that require Symfony dependencies will minimally tracked the latest Symfony LTS release. Where practical, we will allow installation of other Symfony release line. In descending order of priority:

• Older LTS releases while they are still supported
• Latest supported non-LTS release.

[maxime-rainville]

@silverstripe/core-team Any views on this? The proposed policy is just what pop into my mind after a full ten minutes of thinking about it, so I'm not overly protective about it.

[emteknetnz]

Based on the symfony support timeline, the MVP is to just change this sort of thing

from "symfony/cache": "^3.3 || ^4",

to just "symfony/cache": "^4.4",

Then, based on how different the API is, pop in ^4.4 || ^5.4 || ^6.0

Given the good level of unit test coverage we have now, we should be able to run 5.4 + 6.0 through a recipe-kitchen-sink CI run to get a decent level of confidence that things either work out of the box or don't. It should simply be a matter of adding a bunch of aliases in kitchen-sinks composer.json on a fork PR e.g. "symfony/cache": "5.4.3 as 4.4.37"

[maxime-rainville]

@silverstripe/core-team We're looking at upgrading our Symfony constraints in the 4.12 release (that might be release sometime in Sept/Oct). Having consensus on this RFC would be helpful. Could you answer those questions:

1. Do you think having a formal policy on this is sensible?
2. If yes, do you think my proposed policy is a good one?
3. If no, what other criteria do you think we should take into consideration?

[michalkleiner]

I'm not strictly against a policy, though not having one allows us the flexibility to do these things as/when we can/need to. Simply from that perspective, I wouldn't adopt one. Having one forces more work upon the team.

On the other hand, though, it makes Silverstripe CMS as a product more dependable and professional.

50/50 from me.

[emteknetnz]

I'm not too phased by the extra work, so far my experience with symfony has been it's quite easy to adopt new majors because they don't do too much BC changes between majors. Even it if turns out to be a fair bit of work, I see adoption of 'more symfony' as desirable and worthwhile.

I read the work here as:

• Drop 3 entirely (very easy)
• Bump the minimum on everything to ^4.4 (very easy)
• Adopt ^5.4 - run through a kitchen-sink style CI, fix until green
• Adopt ^6.0 on php8+ - run through a kitchen-sink style CI, fix until green

+1 for me

[stevie-mayhew]

I'm okay with this

[maxime-rainville]

In a way, having an actual policy would be less work because we wouldn't have to argue about how we handle various scenario and we wouldn't have to worry about breaking things for people who want to use Symfony version outside of our policy.

[madmatt]

the number of combinations that you might want to support could quickly make running tests a nightmare though - @emteknetnz in your example of running tests against both symfony/cache versions 5.4 and 6.0, what if you add a couple of extra symfony packages with two versions - now if you want to test all combinations it becomes 6 runs through the test suite.

Or am I mis-understanding your suggestion there? Are you just saying there would be (e.g) two runs only - a run of every module at ^5.4 and with every module at ^6.0?

I'm generally in support if you think it will lower the effort, but I do wonder what happens when new symfony major versions come out - do we then violate our policies until we upgrade everything? Feels like it could hit at inconvenient times and mess with the release cycle/cadence.

[maxime-rainville]

Might need to read the fine print of Symfony support policy. At first glance, it looks like the x.4 minor is the last minor for each major release line and becomes the LTS version. So if we were to support ^6.0 for example, we're implicitly support v6.4LTS which hasn't been release yet.

So maybe the policy should be:

• We support the latest LTS
• Once a new major is release, we aim to support that relatively quickly (which sets us up for supporting the next LTS eventually)
• Once we've added support for the new major release line, we drop support for the oldest LTS

[maxime-rainville]

This has been made redundant by #10345