Symfony 2.8 support

[dbu]

continue #325

[wouterj]

This is for the version that supports Symfony 3 right? 🎄

[wouterj]

Not really sure what you do here, as this is closer to "weak" than "strict". I would just set this to strict to see all deprecation notices

[dbu]

unfortunately not, only symfony 2.8. we have a ton of deprecations in 2.8, but i just set travis to ignore them. as discussed in #323 i want to release a version that supports 2.3-2.8 and then we can work on another version that supports 2.8-3.x . supporting 2.3 - 3.x seems impossible because of the different sonata versions we need and all the other problems.

[dbu]

do you think that makes sense, wouter? if you have a better idea that does not end up in a huge amount of work, i am happy to do something more elegant.

[wouterj]

Well, if we don't want to support Symfony 3 in RoutingBundle 1.4, I think we should just not do anything else. The current code works on Symfony 2.8, it just generates lots of deprecation notices (the UrlGeneratorInterface changes can be merged though, as it doesn't require a BC layer).

Then, we can work on RoutingBundle 2.0 and we don't need anymore BC layers, as we can just require Symfony 2.8. As Symfony 3 and Symfony 2.8 support exactly the same public API, it isn't hard to support both versions.

Fortunately, Symfony 2.8 will be supported in Symfony for many years, so companies using the RoutingBundle can use RoutingBundle 2.0 without problems in a Symfony 2.x application. Please note that upgrading from Symfony 2.3 to 2.8 can be done without a single problem. Thinking about it this way, we might also just drop Symfony <2.8 in the next release, except that it would extend 1.3 development time even longer.

As for the value of SYMFONY_DEPRECATIONS_HELPER, I would set it to either weak (indicating that we don't care about the notices, which we do) or 309 (the current number of deprecation notices, so we can spot when we add deprecated usages while fixing bugs).

[lsmith77]

Yeah .. imho lets not add a ton of BC layers in minor versions. instead lets just get these releases out of the door with 2.8 support and then focus on new major versions that require Symfony 2.8+

[dbu]

okay, squashed the commits and set the deprecation helper to 309. i can't set it to weak, as that would result in a build fail (i guess deprecation notices are written to stderr and travis interprets output to stderr as build failure).

@wouterj is the UrlGeneratorInterface change you mention the things that are part of this PR? everything in this PR works fine for all versions, so i intend to merge this. i don't see any other PRs that could be merged at this point.

[wouterj]

i can't set it to weak, as that would result in a build fail (i guess deprecation notices are written to stderr and travis interprets output to stderr as build failure).

Hmm, I'll debug that then, as it could be a bug with the deprecations helper. (stderr is meant for all messages that shouldn't be piped, it's a very confusing name as it actually has nothing to do with errors).

@wouterj is the UrlGeneratorInterface change you mention the things that are part of this PR? everything in this PR works fine for all versions, so i intend to merge this. i don't see any other PRs that could be merged at this point.

Yes. Please note that everything indeed works fine for all versions, as that's exactly what the BC layers do in Symfony. If you aren't going to support Symfony 3, I see no point in having the Sf2CompatUtil in the code base (it only adds complex logic and just using the form type names works in all 2.x versions). Apart from that, feel free to merge

[dbu]

regarding form compat: we already had a hand-built thing in master to run on 2.7 without deprecations. the Sf2CompatUtil just cleans that up. we still have deprecations for symfony 2.8.