[policy, no patch] Follow symfony 2.7 or 3.0., this is the question

I would propose the following, based on what we know from the Symfony website:

1. We focus on Symfony 2.7 for the RC for Drupal 8.0, as well as the first production release. Rationale: We know from the Symfony roadmap that Symfony 2.7 should be released in May 2015, and it is an LTS release. Further, Symfony 3.0 will require a higher minimum PHP version than Drupal 8.0. Currently, the proposal is that Symfony 3.0 will require a minimum PHP version of 5.5, with the possibility that it will be bumped up to PHP 5.6 next year during the Symfony 3.0 development and release process.
2. We also know from the Symfony roadmap that we should have a beta of Symfony 2.7 by the end of February 2015, so we should incorporate the Symfony 2.7 beta into the Drupal 8 beta candidates as soon as it becomes available, then update it as we update the Drupal 8 betas. This will enable us to find any issues early on with Symfony 2.7.
3. In order to prepare Drupal for Symfony 3.0, we should start to make our Drupal code more compatible today by taking the suggestion of the Symfony folks and make the optional suggested changes that are discussed at:
   Upgrade Guide for Symfony 3.0
4. The first release of Symfony 3.0 will not be until November 2015, with the first long-term release (Symfony 3.3) coming out in May of 2017.
5. We can then look at incorporating Symfony 3.x into a future Drupal upgrade (e.g., Drupal 8.1, 8.2, etc.). If we have already taken the upgrade compatibility actions proscribed in the Upgrade Guide for Symfony 3.0, we will have hopefully minimized any serious issues that would result from the upgrade. We would also at that time then need to take a decision to increase the minimum PHP version for Drupal as well.

Just my two cents.

Unless magic happens D10 won't be out at that time.

D9, you mean? :D

EDIT: No, it was D10 — because D8 will be supported until D10 is released. Thanks, Berdir, for pointing that out on IRC :)

This issue assumes that the rules about supporting core releases won't change.
Since the current plan is to continue developing D8, instead of starting D9 right away, it might be safe to drop D8 support once D9 gets released (based on SF3), 3 years after D8.

In any case, avoiding the use of deprecated methods is a worthy goal for D8.

In any case, avoiding the use of deprecated methods is a worthy goal for D8.

+1

+1 to #3, that is a very good rationale:

- Follow 2.7, but avoid deprecated functions from 3.0

So I agree with #3 as well.

Two things I'd add though:

While 8.0.0 is not out yet, we should have a running issue where we can upload patches to upgrade to 3.x and see what breaks. While we very likely will not ever commit those to 8.0.x, it allows us to file upstream bug reports or fix compatibility issues quicker.

Once 8.1.x is tagged, we should strongly consider running that on the Symfony 3.x branch as one of the very first changes - assuming the timing is right to hit 3.0.x with 8.1.0.

The other thing here is that they're dropping PHP 5.4 support. Not sure if this means PHP 5.5 will be a hard requirement for the components we use but that could presumably become the case at any time. We're fine to up the PHP requirements if there's a good reason (see #2301501: [policy, no patch] Explicitly decide and document that mininum requirements for major versions might get raised in minor versions), and keeping up to date with Symfony is a good reason IMO, but that'll need to be announced ahead of time. Not sure if we'd want to support 5.4 a bit longer if that remained possible in practice or not.

So, based on the comments and feedback, here is a straw man summary that incorporates the various comments and feedback:

1. Drupal 8.0.0 will use Symfony 2.7.
2. As soon as Symfony 2.7 beta is released in February 2015, we will incorporate it into the Drupal 8 beta.
3. We will continue to incorporate additional Symfony 2.7 beta releases and then the Symfony 2.7 production release (and future Symfony 2.7.x releases) into Drupal 8.0.x releases, both beta and production.
4. Going forward, starting now, we should start to try to avoid using deprecated methods in Symfony 3.0. In particular, in order to prepare Drupal for Symfony 3.0, we should start to make our Drupal code more compatible today by taking the suggestion of the Symfony folks and make the optional suggested changes that are discussed at:
   Upgrade Guide for Symfony 3.0
5. We should have a running issue where we can upload patches to upgrade to 3.x and see what breaks. While we very likely will not ever commit those to 8.0.x, it allows us to file upstream bug reports or fix compatibility issues quicker.
6. Once 8.1.x is tagged, we should strongly consider running that on the Symfony 3.x branch as one of the very first changes - assuming the timing is right to hit 3.0.x with 8.1.0. We would also then need to upgrade the minimum PHP requirement for Drupal 8.1.x, and can consider any implications of that at that time.

Any thoughts on revisions to this summary?

I am not sure if we can go to Symfony 3.0 with Drupal 8.1. Drupal uses semantic versioning and it means that minor version upgrades can't break backward compatibility. Drupal 8.1 will be a minor upgrade whereas Symfony 3.0 will be a major upgrade and will remove all backward compatibility layers. We will have to put those layers if we want to keep up the promise of semantic versioning.

I am saying "not sure" about this because as far as Drupal components are concerned, we will definitely keep the compatibility or build BC layers. But a contributed module can also use Symfony components (or any other components for that matter). If we upgrade to Symfony 3.0, and thereby remove a BC layer, the module would stop working, which means we don't keep the promise of semantic versioning.

The way I see it, we have to stay on Symfony 2.7 (which is LTS) and move to Symfony 3 with Drupal 9. FWIW, Symfony 3.0 is out in Nov 2015.

Any thoughts?

@hussainweb those are backwards compatibility layers for previous versions of Symfony, but they aren't backwards compatibility layers for previous versions of Drupal - since we'll be on 2.7 when we release. So I think it's OK to just document not to use any deprecated Symfony APIs in this case, and to ensure core isn't using any at all.

I guess it is okay. I am just wondering if this can be considered semantic versioning. It is a tough promise to follow considering such a complex software system. I am okay with it breaking backwards compatibility as long as it is not within Drupal itself and is also well documented. Considering 2.7 will be the last release in 2.x, there aren't chances of any new deprecations in 2.x line after 2.7.

With all this, I guess it is fine, but can we really call this to be a semantic versioning? It is just an academic question but I think it is important just to know the difference and acknowledge that there are exceptions in form of third party components.

@dawehner : self-link :-)

I am only commenting on PHP versions: I think we should open a separate issue for Drupal 8.1 on PHP 5.5. According to http://php.net/archive/2014.php#id2014-08-14-1 PHP 5.4 is at least supported into 2015. I suspect once PHP 7 is out which is scheduled for 2015 Q4 they won't want to support PHP 5.4, 5.5, 5.6, 7 at the same time -- they will be obliged to do PHP 5.5 and 5.6 anyways for quite a while besides the shiny new thing (which I think Drupal 9 should be based on). So by the time 8.1 releases 5.4 will either be EOL or will be very very close to EOL.

I think that finally will be rather popular from 5.5 and possibly generators.

@chx we have #2296557: [policy] Require PHP 5.5 and #2301501: [policy, no patch] Explicitly decide and document that mininum requirements for major versions might get raised in minor versions - between those we're able to move to 5.5 when that's necessary in a minor version.

I haven't seen any objections to TJacksonVA's very nice summary in #11, despite this sitting there for over a week (granted, over the holidays) so adding that to the issue summary and marking this RTBC.

The only thing I'd maybe quibble about there is the last point, because a) we don't know when 8.1.x is going to ship and b) we don't know what hosting/distro support for PHP 5.5+ will be like at that time. But the recommendation only says "strongly consider" not "definitely do it" and I think that this is fine, as long as we take into due consideration the realities at that time.

webchick,

I agree 100% with you. At the time I wrote item 6, I thought it might be an overstatement. I propose the slightly reworded summary below, which only contains changes to item 6:

1. Drupal 8.0.0 will use Symfony 2.7.
2. As soon as Symfony 2.7 beta is released in February 2015, we will incorporate it into the Drupal 8 beta.
3. We will continue to incorporate additional Symfony 2.7 beta releases and then the Symfony 2.7 production release (and future Symfony 2.7.x releases) into Drupal 8.0.x releases, both beta and production.
4. Going forward, starting now, we should start to try to avoid using deprecated methods in Symfony 3.0. In particular, in order to prepare Drupal for Symfony 3.0, we should start to make our Drupal code more compatible today by taking the suggestion of the Symfony folks and make the optional suggested changes that are discussed at:
   Upgrade Guide for Symfony 3.0
5. We should have a running issue where we can upload patches to upgrade to 3.x and see what breaks. While we very likely will not ever commit those to 8.0.x, it allows us to file upstream bug reports or fix compatibility issues quicker.
6. Once 8.1.x is tagged, we can consider running that on the Symfony 3.x branch as one of the changes - assuming the timing is right to hit 3.0.x with 8.1.0. However, that would require us to upgrade the minimum PHP requirement for Drupal 8.1.x, and we can can consider any implications of that at that time, including hosting/distro support.

I think that better reflects the realities.

Lovely. Amended the issue summary with the amended last item. Given that, no further objections. Thanks a lot for your work in synthesizing opinions in this issue. :)

Just made one small pedantic change which was tagged -> branched.

That works great. And we know that 2.7 will be supported for a while, so moving to 3.x in 8.2.x or a later minor release is OK if that's what ends up happening - most important thing is we get on 3.* before the 8.* LTS.

Not sure where this should be documented - maybe a PSA-style change notification for now?

Update summary for #23 and to explicitly mention Symfony 3 dropping PHP 5.4 support.

Looking more closely:

If we decide not to do it for 8.1.x, we can consider again for 8.2.x, 8.3.x, etc., but we must update to Symfony 3.x before Drupal 8 LTS.

Should we change that to Symfony 3.3? So that we peg D8 LTS to a Symfony LTS? And are we concerned at all about 3.3 LTS expiring in 2021?

Specifically, the chart in #2135189: Proposal to manage the Drupal core release cycle suggests we continue security support of D8 LTS until D10 LTS. Symfony 3.3 will come out in May 2017, so D8 LTS will need to be later than that, which seems about right, but then that only leaves <4 years between D8 LTS and D10 LTS, or 2 years per major version. Or, would it be okay during D8 LTS, to bump it from 3.3 to 3.7, which would buy us 2 more years? But even that's "only" 3 years per major Drupal version, which D6-D7 just barely came under and D7-D8 has already exceeded.

I'd hope by the time that Symfony gets to the last LTS release for 3.* and moves onto 4.0, that Drupal 8 is in 'security only' mode - at that point we may be able to persuade upstream to do security-only fixes for the same period. They considered a longer cycle for the 2.7 LTS as a result of this issue. I think that would have been a bad choice for us in this case, and we have no idea how long until support for 8.x LTS is droppped, but it'll definitely be shorter for the 3.* to 4.* move than 2.* to 3.* so might be more feasible when we get there.

I created a change notice here: https://www.drupal.org/node/2403135

Not sure what else to do with this, so marking fixed - if someone thinks of another place to put that information that'd be great.

@effulgentsia I think it's worth discussing what might happen with 8.x LTS support, but probably in a new issue. That's probably a discussion best had once #2362647: [policy, no patch] 8.0.0 release candidates, release, patch versions is further along - since it's about when we decide to open 9.x, cut the 8.x LTS release etc.

I am very sad that I somehow didn't see this issue or any of it's related issues until now. But I am very happy with the outcome. :-) Belated +1 from me!

I should note that the Symfony website currently states that Symfony 3.0 has updated its requirements to PHP 5.5.9.

@dawehner, I agree. We should upgrade to Symfony 2.7 now (Upgrade to Symfony 2.7.0), and then upgrade to Symfony 2.8 when it comes out in November.

As I noted in Upgrade to Symfony 2.7.0, I think the upgrade to Symfony 2.7 should be a Critical item, not a Major item. Drupal 8 is currently using Symfony 2.6.x, which will be end-of-life for bug fixes in July 2015, and end-of-life for security fixes in January 2016. We simply cannot do a Drupal 8 RC with Symfony 2.6.x, so I vote that the Symfony 2.7 upgrade be made a Critical item.