Road to Sonata 4

[greg0ire]

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

• release dependencies (libraries that are required by other sonata libraries). These libraries need to switch to a 3 branch system because of the transition period. ~~ We can revert to a 2 branch system after all dependent bundles have a new major release~~ (won't necessarily be a "4" release, but this is the fourth wave of release, hence the name, Sonata 4).
  • cache
    • reconfigure Travis
    • drop old versions of php & sf Drop old php versions cache#57
    • drop php < 7.1 Drop PHP < 7 cache#59
    • composer outdated is empty Allow predis 1 cache#60
    • remove Extension::addClassesToCompile if present
    • remove most pipes from composer.json on master Drop old versions of dependencies cache#64
  • google-authenticator
    • reconfigure Travis
    • unstick StyleCI
    • drop old versions of php & sf Drop old versions GoogleAuthenticator#40
    • drop php < 7.0 Drop PHP < 7 GoogleAuthenticator#45
    • composer outdated is empty
    • remove Extension::addClassesToCompile if present
    • remove most pipes from composer.json on master Drop old versions of dependencies GoogleAuthenticator#50
  • easy-extends bundle
    • unstick StyleCI
    • drop old versions of php & sf Drop old versions SonataEasyExtendsBundle#103
    • drop php < 7.1
    • composer outdated is empty
    • remove Extension::addClassesToCompile if present
    • remove most pipes from composer.json on master
  • exporter
    • reconfigure Travis
    • composer outdated is (almost) empty
    • drop php < 7.1
    • remove Extension::addClassesToCompile if present
    • remove most pipes from composer.json on master
  • doctrine-extensions
    • reconfigure Travis
    • drop old versions of php
    • drop old versions of sf Drop old versions of Symfony sonata-doctrine-extensions#39
    • composer outdated is empty
    • remove Extension::addClassesToCompile if present
    • remove most pipes from composer.json on master
  • datagrid bundle
    • reconfigure Travis
    • drop old versions of php & sf Drop old versions SonataDatagridBundle#51
    • drop php < 7.1 Drop support for PHP 5 SonataDatagridBundle#77
    • composer outdated is empty
    • remove Extension::addClassesToCompile if present
    • remove most pipes from composer.json on master
      Launch travis target job only if relevant #122
    • drop php < 7.1
    • composer outdated is empty Allow predis 1 SonataCacheBundle#125
    • remove Extension::addClassesToCompile if present
    • remove most pipes from composer.json on master Make sure composer outdated is empty SonataCacheBundle#160
  • formatter bundle
    • reconfigure Travis
    • drop old versions of php & sf Drop old versions SonataFormatterBundle#221
    • drop php < 7.1
    • composer outdated is empty
    • remove Extension::addClassesToCompile if present
    • remove most pipes from composer.json on master
  • Persistence bundles
    • doctrine orm admin bundle
      • drop old versions of php & sf
      • composer outdated is empty Allow simplethings/entity-audit-bundle ^1.0 SonataDoctrineORMAdminBundle#661
      • remove Extension::addClassesToCompile if present
      • remove most pipes from composer.json on master
    • doctrine phpcr admin bundle
      • drop old versions of php
      • drop old versions of sf Stop testing with outdated phpunit-bridge version SonataDoctrinePhpcrAdminBundle#411
      • composer outdated is empty
      • remove Extension::addClassesToCompile if present
      • remove most pipes from composer.json on master
    • doctrine mongodb admin bundle
      • drop old versions of sf Stop testing with outdated phpunit bridge SonataDoctrineMongoDBAdminBundle#201
      • composer outdated is empty
      • remove Extension::addClassesToCompile if present
      • remove most pipes from composer.json on master
    • propel bundle
      • composer outdated is empty
      • remove Extension::addClassesToCompile if present
      • remove most pipes from composer.json on master
  • seo bundle (admin depends on it)
    • reconfigure Travis
    • drop old versions of php & sf
    • composer outdated is empty
    • remove Extension::addClassesToCompile if present
    • remove most pipes from composer.json on master
  • block bundle (admin depends on it)
    • reconfigure Travis
    • drop old versions of php
    • drop old versions of sf Drop old versions of Symfony SonataBlockBundle#352
    • composer outdated is empty
    • remove Extension::addClassesToCompile if present
    • remove most pipes from composer.json on master
  • intl bundle (admin depends on it)
    • drop old versions of php
    • drop old versions of sf Drop old versions of Symfony SonataBlockBundle#352
    • composer outdated is empty Allow matthiasnoback/sf-di-test ^1.0 SonataIntlBundle#150
    • remove Extension::addClassesToCompile if present
    • remove most pipes from composer.json on master
  • classification bundle (3 dependent bundles)
  • user bundle (news depends on it)
    • reconfigure Travis
    • drop old versions of php & sf
    • composer outdated is empty
    • remove Extension::addClassesToCompile if present
    • remove most pipes from composer.json on master
  • media bundle Drop support for old versions of Symfony SonataMediaBundle#1165
  • admin bundle
    • move common template to admin bundle: share common template files through this bundle SonataAdminBundle#2511
    • composer outdated is empty
    • remove Extension::addClassesToCompile if present
    • remove most pipes from composer.json on master
  • admin search bundle
    • remove Extension::addClassesToCompile if present
    • remove most pipes from composer.json on master
  • notification bundle
    • reconfigure Travis
    • unstick StyleCI
    • drop old versions of php & sf Drop old versions SonataNotificationBundle#219
    • drop php < 7.1
    • composer outdated is empty
    • remove Extension::addClassesToCompile if present
    • remove most pipes from composer.json on master
• release dependent, root libraries
  • news bundle
    • composer outdated is empty
    • remove Extension::addClassesToCompile if present
    • remove most pipes from composer.json on master
  • page bundle
    • composer outdated is empty
    • remove Extension::addClassesToCompile if present
    • remove most pipes from composer.json on master
• drop old bundles
  • core bundle
  • cache bundle

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

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

For each library, we should :

• reconfigure Travis on the master branch via dev-kit
• merge the stable branch in master one last time
• drop old versions of php
• drop old versions of symfony
• optionally drop old versions of dependencies
• cleanup NEXT_MAJOR: and deprecated things
• create a $nextMajor.x from master
• alias master to $nextMajor + 1
• for non-leaf libraries, explain the 3-branch system in CONTRIBUTING.md

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]

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 #153.

[greg0ire]

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

Fine by me :) I totally forgot #153

[greg0ire]

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 :
- make sure we support the latest major version, if we don't, add support for it in the stable branch
- in the master branch, drop support for all major versions that are not the latest

[core23]

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]

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]

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

[core23]

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

Refs symfony/symfony#20735

[greg0ire]

I updated the list @core23

[core23]

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]

Would it be a BC break though?

[core23]

Yes https://3v4l.org/iBbmb

[greg0ire]

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

[greg0ire]

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

[core23]

Maybe use the milestones for this?

[greg0ire]

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

[greg0ire]

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]

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

[ethernal]

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]

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]

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

[greg0ire]

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

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

[ethernal]

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

[greg0ire]

Well maybe start upgrading that :P

[JonathanBaudoin]

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]

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]

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]

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

[kunicmarko20]

Drop Symfony < 3.4 on master branches

[mazsudo]

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

[greg0ire]

Thank you! Which part is outdated in your opinion?

[wbloszyk]

@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]

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

[wbloszyk]

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]

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