Symfony 2.4 compatibility

[inmarelibero]

Hi, could you tag a version for Symfony 2.4?

As Fabien explained, 2.4 should be fully backward compatible with Symfony2.3, so maybe changing only composer.json is sufficient.

[vvh-empora]

+1

[pacoVela]

Be careful, if you change the framework-extra-bundle to the last version, you must to fix the GuzzleParamConverter type hinting

[thewilkybarkid]

The problem is that the SensioFrameworkExtraBundle has had a 3.0.0 release, not Symfony (the Symfony Standard Edition now comes with a ~3.0 constraint on the SensioFrameworkExtraBundle, hence the conflict you're seeing).

I would like to avoid having to create a 1.2 to deal with this (and create a 1.1.2 instead which can handle both SensioFrameworkExtraBundle 2.x and 3.x since not that much has changed), but that may be the only option.

In the meantime, you can downgrade your SensioFrameworkExtraBundle constraint to 2.x and it shouldn't change anything (it looks like only some internal bits have changed).

Independent of this, we should remove the SensioFrameworkExtraBundle as a requirement for this bundle, as it's not actually a requirement (see #31).

[thvd]

:+1: Fix this please, so we could use the new Security annotation from the Sensio Framework ExtraBundle.

[thewilkybarkid]

Looks like a 1.2 branch is going to be the only option here.

I think the best approach is to:

• Remove SensioFrameworkExtraBundle as a requirement on 1.1, add a conflict with SensioFrameworkExtraBundle >=3.0.0-dev instead.
• Create a 1.2 branch, containing a conflict with SensioFrameworkExtraBundle <3.0.0-dev | >=4.0.0-dev.

So anyone sticking with SensioFrameworkExtraBundle 2.x can continue to use the 1.1 branch, and for 3.x use the 1.2 branch (and if you're not using it at all you can use either, and aren't forced to download it any more).

Can anyone see any problems with that?

[adrian-ludwig]

+1

[thvd]

:+1:

[thewilkybarkid]

The branches should be set up correctly now, take a look at the dev versions and let me know if it works as expected. If it does, I tag the 2 new versions.

[thvd]

A similar discussion is going on here: https://github.com/FriendsOfSymfony/FOSRestBundle/issues/622

[merk]

@thewilkybarkid that means you've constrained the 1.2 version of the bundle to symfony ~2.4 (just so you're aware)

Regarding the FOSRestBundle problem we want to maintain compatibility with the earliest version of symfony possible so a new version bumping requirements isnt what we're going to do

[thewilkybarkid]

@merk That's why the Travis tests have failed here (I didn't spot the 2.4 dependency); it's not actually tied to ~2.4 though (only if you use the SensioFrameworkExtraBundle). I don't want to have a new branch either, but I don't see a way round it. How are you planning to solve this?

[merk]

The only approach will be to have 2 param converters for both versions of FrameworkExtraBundle and detect which one to use in your bundle's extension class.

[thewilkybarkid]

How would you detect it? Reflection?

[merk]

Looks like thats going to be the only option :\

[merk]

Checkout https://github.com/FriendsOfSymfony/FOSRestBundle/pull/633

[thewilkybarkid]

A bit ugly, but probably better than 2 branches!

I may not have time to do this today/this weekend, so if someone fancies create a PR that undoes the changes in f5510e6515a079505ac7b093d05c8bf0e5db8806 and 613142a6ec7cc467ae1f35893ae202d0c98423d0, and brings in those from the FOSRestBundle PR feel free! (So the master branch reverts back to being 1.1.x-dev and I can then delete the 1.1 branch.)

The Travis config would need changing to, so the Symfony 2.2.0 test uses SensioFrameworkExtraBundle 2.x and the Symfony ~2.2 (which would need to be upped to ~2.4) uses 3.x.