New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Road to Sonata 4 #216

Open
greg0ire opened this Issue Nov 26, 2016 · 28 comments

Comments

Projects
None yet
6 participants
@greg0ire
Contributor

greg0ire commented Nov 26, 2016

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).
    • core bundle
    • cache
    • google-authenticator
    • easy-extends bundle
      • unstick StyleCI
      • drop old versions of php & sf sonata-project/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 sonata-project/sonata-doctrine-extensions#39
      • composer outdated is empty
      • remove Extension::addClassesToCompile if present
      • remove most pipes from composer.json on master
    • datagrid bundle
    • cache bundle
    • formatter bundle
      • reconfigure Travis
      • drop old versions of php & sf sonata-project/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
      • doctrine phpcr admin bundle
      • doctrine mongodb admin bundle
      • 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 sonata-project/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)
    • 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 sonata-project/SonataMediaBundle#1165
    • admin bundle
      • move common template to admin bundle: sonata-project/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 sonata-project/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

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 :

  • 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

This comment has been minimized.

Member

Soullivaneuh commented Nov 28, 2016

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

This comment has been minimized.

Contributor

greg0ire commented Nov 28, 2016

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

Fine by me :) I totally forgot #153

@greg0ire

This comment has been minimized.

Contributor

greg0ire commented Dec 15, 2016

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

This comment has been minimized.

Member

core23 commented Dec 16, 2016

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

This comment has been minimized.

Contributor

greg0ire commented Dec 16, 2016

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 added a commit to greg0ire/SonataDoctrinePhpcrAdminBundle that referenced this issue Jan 5, 2017

Stop testing with outdated phpunit-bridge version
Refs sonata-project/dev-kit#216
This should have been done when dropping support for Symfony < 2.8

greg0ire added a commit to greg0ire/SonataDoctrineMongoDBAdminBundle that referenced this issue Jan 5, 2017

@greg0ire

This comment has been minimized.

Contributor

greg0ire commented Jan 8, 2017

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

This was referenced Jan 21, 2017

@core23

This comment has been minimized.

Member

core23 commented Jan 23, 2017

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

This comment has been minimized.

Contributor

greg0ire commented Feb 11, 2017

I updated the list @core23

@core23

This comment has been minimized.

Member

core23 commented Feb 18, 2017

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

This comment has been minimized.

Contributor

greg0ire commented Feb 19, 2017

Would it be a BC break though?

@core23

This comment has been minimized.

Member

core23 commented Feb 19, 2017

@greg0ire

This comment has been minimized.

Contributor

greg0ire commented Feb 19, 2017

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

@greg0ire

This comment has been minimized.

Contributor

greg0ire commented Feb 19, 2017

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

@core23

This comment has been minimized.

Member

core23 commented Feb 19, 2017

Maybe use the milestones for this?

@greg0ire

This comment has been minimized.

Contributor

greg0ire commented Feb 19, 2017

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

@greg0ire

This comment has been minimized.

Contributor

greg0ire commented Feb 19, 2017

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+

@greg0ire greg0ire referenced this issue Jun 2, 2017

Merged

FOSUser 2.0 #869

4 of 4 tasks complete
@core23

This comment has been minimized.

Member

core23 commented Aug 19, 2017

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

@ethernal

This comment has been minimized.

ethernal commented Sep 20, 2017

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

This comment has been minimized.

Contributor

greg0ire commented Sep 20, 2017

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

This comment has been minimized.

ethernal commented Sep 20, 2017

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

@greg0ire

This comment has been minimized.

Contributor

greg0ire commented Sep 20, 2017

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

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

@ethernal

This comment has been minimized.

ethernal commented Sep 20, 2017

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

@greg0ire

This comment has been minimized.

Contributor

greg0ire commented Sep 20, 2017

Well maybe start upgrading that :P

@JonathanBaudoin

This comment has been minimized.

JonathanBaudoin commented Sep 26, 2017

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

This comment has been minimized.

Contributor

greg0ire commented Sep 26, 2017

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

This comment has been minimized.

JonathanBaudoin commented Sep 26, 2017

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

This comment has been minimized.

Contributor

greg0ire commented Sep 26, 2017

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

@kunicmarko20

This comment has been minimized.

Member

kunicmarko20 commented Apr 14, 2018

Drop Symfony < 3.4 on master branches

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment