search

sonata-project / SonataAdminBundle

The missing Symfony Admin Generator
https://docs.sonata-project.org/projects/SonataAdminBundle
MIT License
2.11k stars 1.26k forks source link

Next Major upgrade process for all bundles - propose #6016

Closed wbloszyk closed 3 years ago

wbloszyk commented 4 years ago

What next major change:

For me we should try make major upgrade process stepable:

Steps to prepare project to this process:

Drop CoreBundle conflict - prepare extensions

Drop CoreBundle conflict - prepare CoreBundle

Drop CoreBundle conflict - update bundles

Upgrade BlockBundle is more anoing

Upgrade 3 => 4 changes

Upgrade option 1 - example

Upgrade option 2 - for me we should use it

Conclusion

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

VincentLanglet commented 4 years ago

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

wbloszyk commented 4 years ago

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

core23 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

wbloszyk commented 4 years ago

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 commented 4 years ago

Done.

wbloszyk commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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-project/core-bundle 4.x should:
sonata-project/block-bundle 3.x and 4.x diff:

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

core23 commented 4 years ago

I'm okay with this, except some cases:

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

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 commented 4 years ago

@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] commented 3 years ago

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.