Prestashop: Upgrade the latest Symfony LTS version

[eternoendless]

Is your feature request related to a problem?

PrestaShop is currently based on Symfony 3.4 LTS which will become EoL late 2021, that's a little more than a year from now.

_Source: Symfony releases_

Since 1.7.8 is due for release early 2021 and probably 1.7.9 won't be out before late 2021, if we don't upgrade Symfony we might end up releasing software based on an unsupported or yet-to-be unsupported framework version.

Therefore, we must consider upgrading to the latests LTS, 4.4.

Describe the solution you'd like

Update to Symfony 4.4

Alternatives you've considered

• Updating to 5.x instead of 4.4 would provide a better path for upgrading to 5.4 when it's out. However, 5.4 is due for release in November 2021, which right now appears as too late for 1.7.9. Choosing a non LTS version from the 5.x branch (say, 5.2) would provide a shorter support lifespan for that PrestaShop release compared to 4.4.

[prestashop-issue-bot[bot]]

Thanks for opening this issue! We will help you to keep its state consistent

[eternoendless]

The first step is analyzing what needs to be done in order to be able to run on Sf 4.4

If the task seems too complex, we can postpone this for 1.7.9

[PierreRambaud]

FYI, we will have to update GuzzleHttp, TranslationsToolsBundle, Circuit-breaker, and many other packages that are not compatible with Symfony 4.

[eternoendless]

Symfony 4 uses guzzle? O_o

[PierreRambaud]

No, but csa guzzle bundle uses

        "symfony/framework-bundle": "^3.4",
        "symfony/dependency-injection": "^3.4",
        "symfony/http-kernel": "^3.4",
        "twig/twig": "^1.34|^2.4",
        "symfony/expression-language": "^3.4"

It's time to update our dependencies instead of continuing forking the world :(

[eternoendless]

You know that updating Guzzle will break a lot of modules

[matks]

@eternoendless we will face this issue over and over in the incoming years. Even if we manage to release 1 major version per year, it will only mean "yeah this is a major update so we cant break whatever we want".

What if the root cause is different?

Hexagonal architecture teaches us not to rely on implementations but on interfaces to allow easy replacement of component. Maybe our mistake was to tell people our Composer dependencies are part of PrestaShop public API.

My question/suggestion is:

• should we continue to say all our Composer dependencies are part of PrestaShop public API? maybe we should define what belongs to it and what does not
• should we start creating interface (exemple: PHPCurlClientInterface) that are being implemented by a Guzzle Adapter, allowing us to modify Guzzle version behind the adapter at will while interface remains backward compatible

[PierreRambaud]

I know, but we can't continue to update forks, it's ugly and against all good practices :/

[eternoendless]

Yes but modules are using Guzzle now. What do we do with that?

[matks]

Yes but modules are using Guzzle now. What do we do with that?

What about

1. we warn everybody that we cannot keep our SemVer promise for Guzzle (and other libs, to be identified) for PS 1.7.9 (= build article)
2. in 1.7.8 we introduce new interfaces and classes to wrap the future implementation and add deprecation messages for existing code
3. in 1.7.9 we perform the upgrade and we write a detailed article about what has been changed and how to update their code

By the way maybe we could look at the upgrade diff right for (step 3). Maybe actually there's not so many differences. Or it could be polyfilled.

[PierreRambaud]

We will have to be compatible with PHP8.0, Symfony 4.4 for the 1.7.8.0 and not only for security reasons. Using old, outdated and unmaintained packages is dangerous :/

[kpodemski]

From my point of view, the faster we warn everybody the less problems we'll have.

IMO communication is the key, let developers know as early as possible and they'll handle it, we know that it's impossible to keep everything backward compatible, I think it's time to stop wasting energy in a fight that cannot be won?

[eternoendless]

The problem is that module developers will be forced to maintain two separate packages for <1.7.8 and >1.7.8, and some developers might take a long time to do that, which may hold back adoption of 1.7.8.

[PierreRambaud]

One day or another, they will have to do it.
We use packages that are not maintained anymore, if they receive security issues, we will not be able to fix it without forking.
I think the solution from @matks is the best one. If we provide interface/helpers to use requests, it will do the job whatever the version of PS you used.