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] Remove deprecated code #5763

Closed core23 closed 3 years ago

VincentLanglet commented 4 years ago

@core23 It's been years since the last major and I feel like the next major is really big with:

What about splitting/prioritizing the needs of the milestone ? What about planning both a 4.0 milestone and a 5.0 milestone ?

For example: 4.0

5.0

The fact that sonata does not support the latest versions of Symfony will impact its popularity.

greg0ire commented 4 years ago

Support for Symfony 5 and Twig 3 can and should go in Sonata 3 I think. Is there anything preventing that?

VincentLanglet commented 4 years ago

Support for Symfony 5 and Twig 3 can and should go in Sonata 3 I think

That would be great.

I misunderstood the following comment https://github.com/sonata-project/SonataAdminBundle/issues/5761#issuecomment-570788139 and thought it was only possible on master.

But making smaller major release can still be a good idea. :)

greg0ire commented 4 years ago

But making smaller major release can still be a good idea. :)

I'm not sure it's worth it actually, I think we were quite careful to add deprecations for most things we removed, and to ask people to add things to 3.x directly, so that releasing 4.0 is a non-event. Maybe it wouldn't be a bad idea to release 4.0 very very soon, after doing everything we can do and 5.0 once we have solved all the issues related to releasing dependencies (which turns out to be a bit painful/longer than expected). @core23 WDYT? Asking you since I think you have a good estimate of where we are at, especially regarding core bundle and block bundle.

core23 commented 4 years ago

But making smaller major release can still be a good idea. :)

I'm not sure it's worth it actually, I think we were quite careful to add deprecations for most things we removed, and to ask people to add things to 3.x directly, so that releasing 4.0 is a non-event. Maybe it wouldn't be a bad idea to release 4.0 very very soon, after doing everything we can do and 5.0 once we have solved all the issues related to releasing dependencies (which turns out to be a bit painful/longer than expected). @core23 WDYT? Asking you since I think you have a good estimate of where we are at, especially regarding core bundle and block bundle.

I created a new milestone for the next next release: https://github.com/sonata-project/SonataAdminBundle/milestone/7

Doing all the remaining stuff that I just moved for the 4.0 release would consume too much time. We need a new major release soonish to get rid of the introduced deprecations.

The good news: We are nearly there. Only 3 (4 with rector) tasks need to be done.

VincentLanglet commented 4 years ago

Why isn't there a wip 4.0 Changelog file ? When removing some deprecated code or adding some BC-break to master, we should add a line to the 4.0 changelog or the update will be hard for the users. Am I wrong ?

greg0ire commented 4 years ago

CONTRIBUTING.md says we are supposed to do this on release:

Also, the following files must be created/updated on the new stable branch:

wbloszyk commented 4 years ago

I'm working on #5597. I made example project for testing. After update SonataAdminBundle to master i had to update DoctrineORMAdminBundles too. So i have some questions:

  1. Do you wanna release major version for all storege-AdminBundle before AdminBundle? There are templates to update too.
  2. What with SonataBlockBundle? Major version is 4.0 but it is not used in AdminBundle. Should we add support for it? Should we drop support for 3.x? For me

For me:

  1. I think major version should be the same for admin and storage admin bundles(becouse it is extension).
  2. we should try make "^3.18.4 || ^4.0". It is nice way to upgrade. Update dependencies, remove deprecations and upgrade AdminBundle. Also it is nice way to update PageBundle.
VincentLanglet commented 4 years ago
  1. Do you wanna release major version for all storege-AdminBundle before AdminBundle? There are templates to update too.

I would say yes

  1. What with SonataBlockBundle? Major version is 4.0 but it is not used in AdminBundle. Should we add support for it?

Yes we want to support 4.0 SonataBlockBundle.

wbloszyk commented 4 years ago

One more thing. What with webpack? It look like @silasjoisten havent time to end it. Should I check it?

VincentLanglet commented 4 years ago

One more thing. What with webpack? It look like @silasjoisten havent time to end it. Should I check it?

Last news seems to be https://github.com/sonata-project/SonataAdminBundle/issues/5863#issuecomment-597458072

You can see with him if you can help if you want. Adding webpack would be great !

wbloszyk commented 4 years ago

Next Major will be replace CoreBundle for other package which will be in conflict with CoreBundle. It is mean bundles with CoreBundle dependencies must have own major realase too. Second support for BlockBundle 3.x must be drop becouse there are CoreBundle dependencies too.

Can we do in all sonata-project bundles in master branch:

  1. Replace CoreBundle by new packages (in more bundles it is done)
  2. Drop support for BlockBundle 3.x and set ^4.0 where CoreBundle is dropped
  3. Update composer.json (php version ..., packages)
  4. Remove CORE from travis and remove unsupported php

Then working on all all bundles will be easy.

Also can you merge #5834 ? It will keep admin working well until webpack release. It is only one directory to delete. I think better keep issues and RP as clear as possible.

VincentLanglet commented 4 years ago

Now we removed CoreBundle, what is currently delaying the 4.0 release @sonata-project/contributors @wbloszyk ?

IMHO webpack is not mandatory an could wait for 5.0.

The 4.0 release is already big, we could work on it now and try to make smaller release 5, 6, ...

jordisala1991 commented 4 years ago

IMO having symfony 5 on Sonata4 could delay the release because if we dont do the BC breaks before release we will not have the chance after release

VincentLanglet commented 4 years ago

Yes, indeed. We also started to add typehint everywhere so we could also finish this.

Last things to do could be

What do you think about starting to release some 4.0-alpha version and for example using them in storage-bundle master branch ?

And maybe the sandbox could use the master branch. Currently there is no way to know if the code is still working on this branch.

wbloszyk commented 4 years ago

@VincentLanglet I working on webpack becouse i need it in my project. Before 4.0 release we should do something with BlockBundle. I mean we should support both version for some time (3.x and 4.x) of all Sonata bundles. This allow upgrade one by one bundle and check it is project working. I see two options:

  1. Add support for BlockBundle 4.x in sonata 3, remove support for 3.x in sonata 4
  2. Keep support for BlokBundle 3.x in sonata 4, bump it some time later
VincentLanglet commented 4 years ago

How do you want to support both version of BlockBundle ? @wbloszyk

The only usage is AbstractBlockService but the constructor changed and the return typehint were added. I thought about it yesterday but I didn't find any solution to stay BC.

The fact that SonataAdmin v3 use Block v3 and SonataAdmin v4 use Block v4 seems ok to me. In the same way, SonataDoctrineORM v3 use SonataAdmin v3 and the SonataDoctrineORM v4 will use SonataAdmin v4.

jordisala1991 commented 4 years ago

To test sonata 4, we should update all sonata master branches to use 4.0@dev, otherwise it is impossible to install it and make it work.

We can create another branch on sandbox after that to see how Sonata 4 works. (or move master to 3.x and use master for 4.x)

wbloszyk commented 4 years ago

@VincentLanglet Look at whole Sonata bundles. It is good idea to force user to upgrade whole bundle (from Sonata3 to Sonata4) at one time? I think we can keep support for BlockBundle3 in Sonata4, becouse:

Some things like extends final block in BlockBundle4 (like MenuBlockService) and is not final in BlockBundle3 can be decorete. API between both version should allow for it. It mean BlockBundle will be the last bundle update in upgrade prccess.

@core23 You also work on Block. WDYT?

wbloszyk commented 4 years ago

@jordisala1991 Better option is add support for 4.x-dev in Sonata3. I will check it tommorow and create TODO list. It is possible.

wbloszyk commented 4 years ago

I run master admin in sandbox by "sonata-project/admin-bundle": "prepare_to_major_master-dev as 3.71.1",. In here issue you can find some information about it and TODO list: https://github.com/sonata-project/dev-kit/issues/780

VincentLanglet commented 4 years ago

I'm currently trying to use sonata-project/admin-bundle: master on sonata-project/doctrine-orm-bundle: master. https://github.com/sonata-project/SonataDoctrineORMAdminBundle/pull/1073/files

I need https://github.com/sonata-project/SonataAdminBundle/pull/6196 and this should be Ok.

core23 commented 4 years ago

Some things like extends final block in BlockBundle4 (like MenuBlockService) and is not final in BlockBundle3 can be decorete. API between both version should allow for it. It mean BlockBundle will be the last bundle update in upgrade prccess.

I've a little lost the track of the recent sonata 4 development. If it is possible to support block 3/4, we should do it. We can remove support for the older version later.

Please keep an eye on the 4.0 milestone. This should help to focus.

VincentLanglet commented 3 years ago

Closing since there is no deprecated code anymore.