Upgrade symfony in lockfile to be 2.8 which is supported version of 2…

[seamuslee001]

….x series

Overview

This upgrades the version of symfony to be 2.8.44 which is the current most stable 2.x branch of symfony. 2.6 is no longer supported upstream

Before

Unsupported version used

After

Supported version

ping @eileenmcnaughton @totten @mlutfy @monishdeb

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[totten]

Release notes for upgrading 2.6=>2.7 and 2.7.=>2.8

We don't use many components, so most of it should be safe. Some things which popped out:

• 2.8: All components - We should probably add the iconv polyfill? Based on a quick grep, I don't think we've really been using/requiring iconv, and all the references that come up include guards.
• 2.8: Config - Civi\Core\Container does use the isFresh() check
• 2.7: Global - Interesting bits about deprecations and testing, but this feels optional.

[totten]

Also, an observation we raised in Mattermost -- anyone using Civi with D8/composer is already running Symfony 3.x, which alleviates some concern about compatibility issues in newer 2.x/3.x.

[monishdeb]

Yes true about the compatibility issue as the latest D8 uses Symphony 3.4 that requires 5.5.9 and above. So I need to update composer with symphony/*: ~3.4 But we cannot update S to 3.4 as it might raise issues with php5.3 as @seamuslee001 indicated in MM channel

[eileenmcnaughton]

@monishdeb we don't support 5.3so that doesn't matter.

We talked on MM about 5.5.9 - but the 5.5 series is up to 5.5.39 - I don't think we need to worry about dropping the very earliest 5.5 versions -if people are on 5.5 we can reasonably assume they are not on the very oldest releases of it

[monishdeb]

@eileenmcnaughton oh ok. I see the min PHP supported by Civi as per CRM_Upgrade_Incremental_General::MIN_INSTALL_PHP_VER is 5.5. So I think we can use ~3.0 instead of 2.8 to resolve the compatibility issue with the latest D8 release?

[eileenmcnaughton]

@monishdeb if 3.x solves a problem that seems like a strong case for going to it - @mlutfy advises he has 3.4 deployed live on drupal 8 sites

[monishdeb]

Yes, even I have deployed 3.4 in 2 staging sites and its working fine.

[seamuslee001]

yeh i would be ok going with 3.x but i suspect there maybe more changes but i'm not sure the consequences of the implications in the symfony stuff. I was just thinking minor update might be easier than doing a major upgrade but happy to go the latter if people think we can do it

[JoeMurray]

Symfony 3.x has long term support until Nov 2020 unlike Symfony 4.x which loses support Jan 2019 https://symfony.com/download

I'd encourage doing a single bump up to 3.x rather than two, to latest 2.x then a different one to 3.x latest. But that depends of course on investigating issues and scoping effort. We could contribute some of Monish's time to help.

[eileenmcnaughton]

I'm not too worried about 4.1 losing support in Jan as 4.2 will be available & supported & it's a minor difference. However the 4.x series is not an option to us due to our supported php versions

Symfony 3.4.1 support is good for us.

I'm going to merge this as I think we can go up to 2.8 regardless of whether we go up to 3.4.1 in 2days or 2 months. It seems it is pretty safe & fixes a drupal 8 issue so the rc process + live testing to date by @mlutfy & others makes me comfortable with going to 3.4.1