Add DoctrineBundle^2.0 compatibility for CmsBundle^3.1

[Amunak]

The upgrade to doctrine/doctrine-bundle 2.0 is not exactly trivial, but I don't think it should be a major issue. (At the same time supporting ^3.0 is trivial, so you may add that as well if you manage ^2.0).

CmsBundle 4 is not out yet, and this is a pretty major hold-back in dependencies. Most notably this means anyone using CmsBundle has a forced dependency on some abandoned zendframework/* packages.

Can you please look into it? I assume that if there are any changes needed they can be backported from CmsBundle 4.

[Pierstoval]

The v4 is out yet already: https://github.com/Orbitale/CmsBundle/blob/4.x/composer.json#L11

I tagged it as a "pre-release" because the audience for this project is not active enough to be sure that 4.0.0 is 100% stable, but I'm using it on 2 projects already and it's okay :) And it uses DoctrineBundle 2.0

We might make v3 compatible with DoctrineBundle 2.0, indeed, so if you want to make a PR, you're welcome, I'll gladly review it and release a new version of v3 with it 😄

[Amunak]

Unfortunately we can't really use v4 either, as it's locked to SF5. Do you use any of the new features that make it impossible to be compatible with SF4.4? Stable projects like the one we have unfortunately can't really afford to be on maintenance releases that need to be updated twice a year.

And if v4 is more or less ready, will there be an UPGRADING manual somewhere? Obviously the dependency requirements changed and some service configuration, but is there anything else?

if you want to make a PR, you're welcome, I'll gladly review it and release a new version of v3 with it

I kind of hoped that since you already went with it to make V4 that it wouldn't be too hard to backport :w

[Pierstoval]

Unfortunately we can't really use v4 either, as it's locked to SF5. Do you use any of the new features that make it impossible to be compatible with SF4.4?
(...)
And if v4 is more or less ready, will there be an UPGRADING manual somewhere? Obviously the dependency requirements changed and some service configuration, but is there anything else?

Nope, major was released mostly because of new PHP and Symfony version constraints. There's also a change, since I removed behat/transliterator and replaced it with symfony/string, but this should be transparent for the user.
I also released the new blog controller in the new major.
Most BC breaks are the following:

• I removed Category::$createdAt.
• I replaced DateTime with DateTimeImmutable in the Page fields.
• I also added validation constraints which may break BC if using Pages with Symfony Forms already, but this shouldn't really break that much, this is mostly for consistency.
• And finally, the service names changed to use only the FQCN, so the old ones are not available anymore.

All of this is in the v4.0.0 changelog there: https://github.com/Orbitale/CmsBundle/releases/tag/v4.0.0 , just not explicitly marked as BC break, but I can make it clearer if you think it's important :)

Stable projects like the one we have unfortunately can't really afford to be on maintenance releases that need to be updated twice a year.
(...)
I kind of hoped that since you already went with it to make V4 that it wouldn't be too hard to backport :w

I totally understand, that's why I'm okay to attempt to backport stuff to v3 if you really need😄

[Amunak]

All of this is in the v4.0.0 changelog there: https://github.com/Orbitale/CmsBundle/releases/tag/v4.0.0 , just not explicitly marked as BC break, but I can make it clearer if you think it's important :)

I did read the changelog, but being specific about BC breaks is IMO very important, so if you can make it clearer, yes, please! Some projects go as far as having a dedicated file for changes, which is amazing for the bundle users and inspires confidence in the project as a whole.

I totally understand, that's why I'm okay to attempt to backport stuff to v3 if you really need

Uff, If you'd be doing it just for me perhaps don't x)

Alternatively you could perhaps verify that v4 works under SF4.4 then that would also be a reasonable upgrade path.

Regardless, thank you for your effort.

[Pierstoval]

I already switched from releases notes to a Changelog file on Compotes, but not yet on all other packages, I'm going to do it 🙂 (Edit: it's done for CmsBundle! 😉 )

For the rest, I could check if the project works on SF 4.4 , but I am not sure it's a good idea yet, because the biggest step forward IMO is the PHP 7.1->7.3 version requirement, so I'd better do the change on 3.x, WDYT? Or do it on both versions?

It's gonna be more work, and I currently have some other priorities 😅

[Amunak]

Thanks for the changelog!

For the rest, I could check if the project works on SF 4.4 , but I am not sure it's a good idea yet, because the biggest step forward IMO is the PHP 7.1->7.3 version requirement, so I'd better do the change on 3.x, WDYT? Or do it on both versions?

For me personally requiring PHP 7.3 but allowing SF 4.4 would solve the issue.

Nobody should be on 7.1 anymore as it's unsupported, and 7.2 is on its way out as well:

[source - Packagist stats]

So I think it's reasonable to keep supporting only PHP7.3, but still keeping compatibility with SF4.4 for people who want the LTS version of Symfony. I mean, 4.4 should otherwise be identical to 5.0 (barring new features and removed stuff that was deprecated in 4.4).

Then once SF 5.4 releases (in 1.5 years; it will also be LTS) you could eventually make another BC breaking release and drop support for everything but 5.4, but primarily support 6.* with whatever smallest version that supports and essentially repeat the cycle.

[Pierstoval]

When I have more time for this specific subject, I'll probably update v3 and v4 and check the "lowest compatible SF version" :)

Is it urgent for you?

[Amunak]

Not at all; I just noticed that CmsBundle was the only package holding back the (already fairly old) doctrine-bundle v1. If I can update it next time I update the project's dependencies that's as good time as any.