Sonataadminbundle: Next Major upgrade process for all bundles - propose

[wbloszyk]

What next major change:

• close api
• add return type hints
• drop CoreBundle
• upgrade BlockBundle 3 => 4
• drop/update/add dependencies
• add features

For me we should try make major upgrade process stepable:

• upgrade project to the newest minor version
• drop dependencies
• upgrade BlockBundle and add return hints for own blocks
• upgrade one by one others sonata bundle

Steps to prepare project to this process:

Drop CoreBundle conflict - prepare extensions

• add conflict in form/twig-extensions "sonata-project/core-bundle": ">=3.13 || <=3.18"
• clone extensions to new branch - and remove return type hints
• release new extensions versions like 0.3 and 1,3
• i think recipe is requre here to add bride bundle

Drop CoreBundle conflict - prepare CoreBundle

• drop Sonata/ -form/ -twig in CoreBundle
• and extensions in 0.x version
• release CoreBundle minor version 3.19,

Drop CoreBundle conflict - update bundles

• allow use ^0.3 || ^1,3 extensions if they are use in any project also with major x.0 version
• drop support for ^0.3 version in major x.0.1 patch

Upgrade BlockBundle is more anoing

Upgrade 3 => 4 changes

• change in API
• add return type hints

Upgrade option 1 - example

• remove AbstractAdminBlockService and AdminBlockServiceInterface
• copy all blocks to block4, upgrade it to BlockBundle 4

Upgrade option 2 - for me we should use it

• in BlockBundle replace tag 4.0.0 for BlockBundle 4 code without return type hints
• upgrade blocks like in this commit
• allow use only BlockBundle 4.0.0 in current bundles

Conclusion

Return type hints is the most BC-break thing in next upgrade.

[VincentLanglet]

I thought the type hints would be in the 5.0 release. The 4.0 is already pretty big.

[wbloszyk]

@VincentLanglet sorry, my bad. I talking about all project. Anyway it is better think about it now.

[core23]

Thanks for your listing @wbloszy ❤️

We already have an internal road map and a road to sonata 4 issue on our dev-kit. The steps your are mentioning are exactly our steps. Our main problem is time. We all want to release new major versions, but we have not enough time to finish this steps soon.

IMHO we made a mistake when we moved the core bundle to the new extensions repos. We should have made a 1:1 made a copy & paste of the original sources. But we added type hints and made some API changes. The only way to solve this issue in a smooth way is to backport the code to the extensions repo and release them as 0.x versions or we have hard BC breaks which will cause some pain if you want to upgrade to sonata 4.

Btw. there is a milestone with the (last) steps we need for the admin bundle: https://github.com/sonata-project/SonataAdminBundle/milestone/6

[wbloszyk]

Thanks for informations. I don't know AdminBundle code very well. I will cofus to end AdminLTE upgrade and webpack. Then I will check what must be do to prepare extensions in 0.x version.

[wbloszyk]

@core23 I almost done #5989. I can not finish it on dependencies part like UserBundle. I check diff CoreBundle with extensions. It is possibile to create backport from 1.2 versions. Bundle config must stay in Core, extensions should have own too, and 0.x extensions must required Core. This will resolve composer version, but make another one. 0.x should be equal to 1.x but without return Types hints. Are you agree? I will work on it. I will finish it on jest week, becouse need free weekend.

[greg0ire]

I just realised this morning that removing a return type declaration is not a BC-break. How about we remove them (or at least, the ones that prevent us from upgrading) in 1.x, and then add them back in 2.x?

[wbloszyk]

There are also other change in API, like add support for contracts, drop support for some parameters. Remove return Types hints is not bc-break becouse user can add, but cant delete them. So we have 2 options:

1. Relase 0.x version
   
   
   
   • merge Core code with 1.x
   
   
   • next relases must based on 1.x version
   
   
   • 1.x update can be done in 0.x, then merge and add return Types hints
   
   
   • i have done it on own repository, todo is merge tests only
   
   
2. Remove return Types hints
   
   
   
   • less work, but what with API change
   
   
   • we have to add it back in 2.x
   
   

Also remember 1.x is relased and someone can use it now. Add support for older version is strange thing. Also 0.x should be support as long as Sonata3 is - i think not long.

For me: option 1

[greg0ire]

Ok for option 1 too, I did not have the API changes in mind.

[wbloszyk]

Can you create 0.x branch from 1.2 tag for form and twig extensions? I will try finish it in Tuesday. I will also use it in #5989 demo, so i will check on practice how this upgrage process work.

[greg0ire]

Done.

[wbloszyk]

WDYT should we release CoreBundle 4.0 for use 0.x extensions? Remove extensions from Core required drop some service and is bc-break so i think it good way to force user to drop it. 4.0 can be used like check is bundle "ready for sonata 4". Also this will be good "first step" in sonata upgrade process.

[greg0ire]

It might make sense yeah :)
So IIUC, core bundle 4 would be an empty shell requiring 0.x extensions, correct? And services defined in it would become deprecated aliases to extension services?

[wbloszyk]

At first Core must drop all duplicated code (which is move to extensions). Later all other code must be mark as deprecated but mast stay in bundle to keep BC. After upgrade all bundles (ALL!!!) to Sonata 4 user should drop it. So:
Add CoreBundle 4 - to start upgrade.
Remove CoreBundle 4 - all code is upgraded.

BTW I finish work on 0.x extensions and Core 4. Now I am working on deprecations notice and tests.

[wbloszyk]

@greg0ire @core23 and other @sonata-project/contributors WDYT?

I just relized something. I chek it and it is work. We can resolve upgrade problems by SonataCoreBundle 4.

sonata-project/core-bundle 3.13+ contains:

• Sonata\CoreBundle*
• Sonata\Form* - form-extensions legacy
• Sonata\Serializer* - move to form-extensions
• SonataTwig* - twig-extensions legacy

sonata-project/core-bundle 4.x should:

• contains only Sonata\CoreBundle
• required form-extensions 1.3 (with serializer)
• required twig-extensions 1.2
• drop all service whitch was moved to extensions,
• drop all deprecated code which is not required to Sonata 3 work,

sonata-project/block-bundle 3.x and 4.x diff:

• change AbstractAdminBlockService it to EditableBlockService
• drop AbstractAdminBlockService and AdminBlockServiceInterface
• close API
• add return type hints

Conclusion:

1. block-bundle 4.x is "Sonata 4" and should not be install in any "Sonata 3" package
2. block-bundle 3.x should be allow install in "Sonata 4"
3. block-bundle 3.x should required core-bundle 3.x || 4.x to resolve extensions conflict
4. core-bundle 4.x should required extensions 1.x
5. core-bundle 4.x and block-bundle 4 should be in conflict
6. backport extensions is propably not required

becouse

1. Return type hints make BC-break
2. This will allow use old block (cross install between Sonata 3 and 4 will be allow)
3. Using core-bundle 4 will allow install some Sonata 4 bundles
4. Using core-bundle 4 will allow install some Sonata 4 bundles
5. We can force user to fix own code in core-bundle MAJOR upgrade

summary

• core-bundle 3.x - use only Sonata 3
• core-bundle 4.x - use Sonata 3 or Sonata 4
• drop core-bundle use only Sonata 4

[core23]

I'm okay with this, except some cases:

sonata-project/core-bundle 4.x should:

• not be released

IMHO we could resolve the return type conflict by removing all return types in our *-extensions repos. And add them back with the next major version of the extensions.

[wbloszyk]

@core23 I add two issues which you should see and check. This will resolve some upgrade problems.

https://github.com/sonata-project/SonataCoreBundle/issues/739
and
https://github.com/sonata-project/SonataBlockBundle/issues/700

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.