Upgrade to Symfony 4

[Boldie]

Upgrade Symfony framework to Version 4. For the Moment Version 2.7 is used.

Drawbacks: PHP7.1 as minimal requirement.

Here is some information about upgrading it: https://github.com/symfony/symfony

I was unable to find information of Upgrading from 2.7 to 3

[Boldie]

Is it really medium? I think it refers to #1065 but in my opinion we should not make an upgrade to 3, because it is already unmaintained and outdated.

Upgrading symfony will completely restructure big parts of the code. So we should first add every pending pull request, otherwise they will be no longer compatible.

[christianlupus]

The thing is that we are on 2. We might get on 3 on order that the tutorials in the link are of help. These start at 3. So we need to go to 3 and then to 4 as far as I see it. As soon as we are ready to get it, we will march foreward I hope.

[christianlupus]

Regarding the upgrade documentation there is something I just found here. Just for reference.

[Boldie]

Urgs, another long list of stuff what one has to do. I also read there are some ways forth and back if one will look from 2 to 4, so maybe it is more favourable to directly upgrade to 4. I will try to read this if I have some time the next days and hopefully I will get a better insight of the needed actions. I love "fancy" frameworks changing everything from one version to the next :)

[christianlupus]

Well if you are willing to share the 2->4 version guide, I would be grateful. This would allow us all to look over things...

I love "fancy" frameworks changing everything from one version to the next :)

You should read this or this on semantic versions. If a major number changes, this means a potential redesign of the whole API. So your request 2->4 is in fact 2 times a redesign of the API. Congratulations if you could manage such a change without the need to change the code of any using software.

[baradhili]

@christianlupus not really.. I think Symfony follows the "if its even its a release" rule... eitehr way - upgrading teh underlying framework can be a real pain.. I was thankful that Laravel made 5->6 easy

[dromer]

I agree we should get the current bugfix-PRs merged first, then focus on the symfony upgrade.

The upgrade-path is less important than reaching a version that has long-term support I think, although API changes of course should be noted. At the moment the LTS is 4.4.x which should get updates till 2023: https://symfony.com/releases But getting to 3.4.x would already be a fantastic milestone, considering where we are now.

[christianlupus]

I consider a good debug environment essential for such a huge modification. Thus, I will try to get #1071 ready as soon as possible. I have still to think of some details. With that experimenting around should be much easier.

Sorry, I assumed ther versioning scheme was the typical semantic one. This was my fault.

[dromer]

@baradhili I'm pretty sure they use semantic versioning like @christianlupus said.

Also found this guide which may be useful: https://symfony.com/doc/current/setup/upgrade_major.html

I think incremental upgrades (first to 3.4.x and then to 4.4.x) would be recommended as at each stage some features are deprecated.

[christianlupus]

There is some useful information at the ending in this document.

Backward Compatibility

When a feature implementation cannot be replaced with a better one without breaking backward compatibility, Symfony deprecates the old implementation and adds a new preferred one along side. Read the conventions document to learn more about how deprecations are handled in Symfony.

This deprecation policy also requires a custom development process for major versions (4.0, 5.0, 6.0, etc.) In those cases, Symfony develops at the same time two versions: the new major one (e.g. 4.0) and the latest version of the previous branch (e.g. 3.4).

Both versions have the same new features, but they differ in the deprecated features. The oldest version (3.4 in this example) contains all the deprecated features whereas the new version (4.0 in this example) removes all of them.

This allows you to upgrade your projects to the latest minor version (e.g. 3.4), see all the deprecation messages and fix them. Once you have fixed all those deprecations, you can upgrade to the new major version (e.g. 4.0) without effort, because it contains the same features (the only difference are the deprecated features, which your project no longer uses).

[er1z]

There's always a help of Rector with upgrades. You don't have to manage everything.

[dromer]

@er1z do you mean https://github.com/rectorphp/rector ?

I would feel much more comfortable if someone is able to debug such automagic :#

It sounds a bit dangerous to me. I don't know what the current coverage of the builds are since that part of the travis-ci seems to be missing some configs, but i'd feel safer about automated refactoring with a good overview of unit-tests and code-coverage.

The promises on the project page are very enticing though ;) So still worth the experiment to see what comes up.

[er1z]

Yeah but it'll decrease amount of manual work to be done. This is a well-known tool created by an experienced developer.

[christianlupus]

Increasing priority as this seems to be the most pressing issue according also to other disussions here.

[dromer]

I'm trying to test rector on my local machine (with php7.3), not much luck yet.

I'm still not convinced this will be 100% safe to do, but perhaps to make some of the incremental migrations it will at least give some insight into what needs to happen.

[er1z]

Yeah, but any help to decrease amount of work in order to upgrade is worth trying. No one guaranteed that it will be fully automatic. ;)

But yeah, going straight to 4.x will be better than jumping over 3.x. It's possible to just port most of the functionality without complete rewrite of whole application.

[christianlupus]

@er1z do you have experience with rector? I tried it today but without much success. If you had experience with it, it would be awsome, if you could have a look and give us a hint in the right direction...

[G-Pereira]

Amazing work this is! When this is ready will it be possible to upgrade existing installations? I am worried about compatibility and I am wondering if I should wait for this to be ready before starting to register my components. By the way is there any docker file I can use?

[christianlupus]

When this is ready will it be possible to upgrade existing installations? I am worried about compatibility and I am wondering if I should wait for this to be ready before starting to register my components.

We are working to keep things either compatible or automatically upgradeable. We are not the only project that might need a facelift from time to time. As the upgrade process might take quite some time, I would personally rather not wait if you find your time at the moment.

By the way? Is there any docker file I can use?

We are working on something, see #1088. However, this is still under work and review thus I cannot give you a definitive answer when it will be available. I personally run the version of mhubig at the moment.

[G-Pereira]

@christianlupus That is useful information, thanks!

[arthurlutz]

I'm hoping to run partkeepr on a debian buster which has php 7.3. I'd be interested in this upgrade too. (unless there is another open issue on possibilities of running partkeepr with 7.3 ?)

[dromer]

I think everybody is "interested" in upgrading our dependencies to more modern requirements.

The problem is that we really need someone with experience to help with this. Please refrain from "+1" and "me too" posts in this thread, I think we all have the same goal here :)

Otherwise: no, it is currently definitely not possible to run partkeepr with php >7.1 So you will really have to wait until the dependency issues are resolved.

There are unofficial php-7.1 packages available for buster in the mean time