sonata-project / dev-kit

Development kit of the Sonata-Project
https://master-7rqtwti-ptm4dx6rjpjko.eu-5.platformsh.site/
42 stars 42 forks source link

Road to Sonata 4 #216

Closed greg0ire closed 3 years ago

greg0ire commented 7 years ago

Here's a meta issue to rule them all. If you can edit, don't hesitate to add items.

Here is a deps graph generated with clue/graph-composer deps

Here is the same graph, with sonata-deps only (I deleted things manually with inkscape) deps svg

For each library, we should :

About libraries, I think maybe we should support only one major version of a given library, and give doctrine/orm a special treatment, maybe by supporting only the two last minor releases. Thoughts?

soullivaneuh commented 7 years ago

We can revert to a 2 branch system after all dependent bundles have a new major release

No, the goal is exactly to keep a three branches system. :-)

Please see https://github.com/sonata-project/dev-kit/issues/153.

greg0ire commented 7 years ago

No, the goal is exactly to keep a three branch system. :-)

Fine by me :) I totally forgot #153

greg0ire commented 7 years ago

About libraries, I think maybe we should support only one major version of a given library, and give doctrine/orm a special treatment, maybe by supporting only the two last minor releases.

@sonata-project/contributors , can you give me your feeling about this ? It feels lonely here!

In more detail, I think the ideal plan would be

given a dependency :

core23 commented 7 years ago

Good work @greg0ire !

Before releasing the next major release of the admin bundle, there are still some stuff to do to have a clean new admin solution: https://github.com/sonata-project/SonataAdminBundle/milestone/6 IMHO it's the perfect time to remove some old edges, e.g. the overcomplicated AbstractAdmin class.

For the branch system: What about supporting the oldest version (version 3) with security patches for just one year when releasing the next major release (version 4). This would leave a clear sign to the people who are using old (outdated) software and would concentrate our power to the evoltion of our software.

greg0ire commented 7 years ago

What about supporting the oldest version (version 3) with security patches for just one year when releasing the next major release (version 4). This would leave a clear sign to the people who are using old (outdated) software and would concentrate our power to the evolution of our software.

I think it's the plan :)

What do you think about the support plan I proposed for dependencies other than Sonata or Symfony?

greg0ire commented 7 years ago

For instance, for SonataMediaBundle, that would mean dropping support for FosRestBundle 1, jms/serializer 0, and gauffrette 0.1. what say you

core23 commented 7 years ago

We should also drop all Extension::addClassesToCompile for the next majors, because this part is only needed for < PHP 7.

Refs https://github.com/symfony/symfony/pull/20735

greg0ire commented 7 years ago

I updated the list @core23

core23 commented 7 years ago

What about PHP 7 type declarations? We've completly dropped PHP 5 support, so we could use the new type hinting stuff for every method.

greg0ire commented 7 years ago

Would it be a BC break though?

core23 commented 7 years ago

Yes https://3v4l.org/iBbmb

greg0ire commented 7 years ago

You're getting it backwards again 😅 But anyway, you're right 👍

greg0ire commented 7 years ago

@sonata-project/contributors the big checklist is getting unwieldy. Maybe we could create a "project" like this for every repo?

core23 commented 7 years ago

Maybe use the milestones for this?

greg0ire commented 7 years ago

We would have every issue listed here in one "next major" milestone, so I don't think milestones would be useful here.

greg0ire commented 7 years ago

so we could use the new type hinting stuff for every method.

Started it on the cache library, it's an ordeal for us, and probably will be for our users. Also there's an RFC which could make this way more doable when we use php 7.2+

core23 commented 7 years ago

For all bundles: we should drop PHP 7.0. Travis is already set up.

ethernal commented 7 years ago

Any news on progress and BTW will Symfony 4 be supported? Maybe skip the 3.0 or at least release one that supports 3.0 and then focus on 4.0

What are the plans? If SF 3.0 is getting support around or after SF 4.0 is released what are the chances of staying up to date?

greg0ire commented 7 years ago

I'm keeping the todo list up to date, we have 3 packages ready for release IIRC

SF 4 support will probably be added as soon as sf 4 is out.

ethernal commented 7 years ago

That means FOS2 is also compatible with SF4? That's a relief ;-)

greg0ire commented 7 years ago

That means FOS2 is also compatible with SF4? That's a relief ;-)

I'm not speaking for FOS, don't jump to conclusions.

ethernal commented 7 years ago

I thought so.. ^_^ I'm still stuck at SF 2.8

greg0ire commented 7 years ago

Well maybe start upgrading that :P

JonathanBaudoin commented 7 years ago

As I said here, my company would like to help. But as often, some members do not realize the difficulty of apprehending a huge project like Sonata. Explanations pages (for PR for example) are not necessarily sufficient. But OK, if it's the only way to do it... It is too bad to discourage people who wish to help.

Were are going to use a specific commit.

greg0ire commented 7 years ago

Did you read the CONTRIBUTING.md ? We tried to explain at length how to contribute there. If you want to help, I think you might want to get doctrine-extensions closer to the goal. You can have a look at https://github.com/sonata-project/cache/projects/1 to see how it went for other projects.

It is too bad to discourage people who wish to help.

Why are you saying this? Because you did not get the lengthy answer you hoped yet? Most of us are working right now, I'm sure you understand that.

JonathanBaudoin commented 7 years ago

We read it. But as I said, it's not easy to apprehend a huge project like Sonata. There are a lot of things, and we don't know all of them (you know, the rest of the world doesn't). I didn't say that because I dit not get the answer I hoped... I did say that because we want to help but are not familiar with the Sonata workflow proccess, and it seems there are a lot of things to do with a lot of bundles. And, to resume, the @Soullivaneuh answer is: "do a PR". OK. Thanks. I was asking some human help to help Sonata. That's too bad.

I don't know, a company offers to help, maybe it might have been interesting to talk with these people instead of closing the discussion by referring to a procedure.

Sorry for my expression, we can continue in french by mail if you want. ;)

greg0ire commented 7 years ago

You can also come on #sonata on the symfony-devs slack. We might even start a french thread in there if you want.

kunicmarko20 commented 6 years ago

Drop Symfony < 3.4 on master branches

mazsudo commented 4 years ago

@greg0ire very nice list ;) any chance to get it updated to help to move forward on the road to Sonata 4 🎉?

greg0ire commented 4 years ago

Thank you! Which part is outdated in your opinion?

wbloszyk commented 4 years ago

@greg0ire I think we this issue can and should be update. WDYT?

We should also make CacheBundle optional in PageBundle to drop this deprecated bundle. @sonata-project/contributors Mybe someone od you have expirience with cache and can do it?

greg0ire commented 4 years ago

Uh yeah maybe? What specifically needs to change in the many checkboxes above?

wbloszyk commented 4 years ago

CoreBundle and CacheBundle should be move for drop sonata-project abbadoned packages.

Probably we should not cafe about drop old version od PHP/symfony in package like -extensions.

I will try check it in this week. Will be nice to know im which place we are now.

VincentLanglet commented 3 years ago

Closing as we made some 4-rc releases and not following the checklist