3.0.0 release todo

[soullivaneuh]

Issue updated since #3731 (comment):
This will not be 2.4 but 3.0. See reasons:

• dev-master has already several BC breaking modifications that was merged (sigh)
• Pushing a major release would prevent other stable sonata bundle to auto-update to the new version and might be failed
• This will be the occasion to make a real separation between the old and the new versions management

Since this time, if you're requiring sonata-project/admin-bundle 2.4.*@dev on composer.json, you have to change to 3.*@dev, 3.x-dev@dev or dev-master@dev.
This is the only breaking change.

For possible dependencies issues, see #3731 (comment).

PLEASE DO NOT POST YOUR DEPENDENCIES ISSUES HERE

This issue is not here for that. If you tried previous solutions and are still stuck, please open another issue on the concerned project.

Even if it's a new major, no BC breaking Pull Request will be merge until 3.0.0 release.
The reason is simple: Lot of user are already using dev-master version of sonata-admin and we didn't tag minor/major releases from a long time. Let's do it painless.

This issue goal is to list all to do things that we must do before and after tag this version.

To many changes between 2.3 and master branch, we have to take precaution.

This issue will be a model for another repository minor tag before start the new release process management.

Before tagging

Internal changes

• Change 2.4.x-dev to 3.x-dev on composer.json (Good bye 2.4, welcome 3.x! #3732)
• Change deprecation comment and warning from 3.0 to 4.0 and 2.4 to 3.0. (Thanks @greg0ire for remember) (Replace deprecation messages and comment for 3.0 #3733)
• Change / reset milestones

Internal dependencies issues

List etablished from composer show --all sonata-project/*.
Not all packages need to be updated.

• sonata-project/admin-bundle
  (will be 3.x):
  • Composer improvements #3751
• sonata-project/admin-search-bundle
  (will be ?):
• sonata-project/block-bundle
  (will be 3.x):
  • Composer fixes and improvements SonataBlockBundle#259
• sonata-project/cache
  (will be ?):
• sonata-project/cache-bundle
  (will be ?):
• sonata-project/classification-bundle
  (will be 3.x):
  • Composer fixes and improves SonataClassificationBundle#183
  • Sonata media-bundle 3.x-dev@dev SonataClassificationBundle#184
  • Using Sonata stable versions on composer SonataClassificationBundle#189
  • 3.x Branch for compatibility with Admin 3.0 SonataClassificationBundle#190
• sonata-project/comment-bundle
  (will be ?):
• sonata-project/composer-archive-creator
  (will be ?):
• sonata-project/core-bundle
  (will be 3.x):
  • Composer improvements SonataCoreBundle#240
• sonata-project/dashboard-bundle
  (will be ?):
• sonata-project/datagrid-bundle
  (will be ?):
• sonata-project/doctrine-extensions
  (will be ?):
• sonata-project/doctrine-mongodb-admin-bundle
  (will be 3.x):
  • Is this bundle compatible with admin 3.0 (old 2.4)? SonataDoctrineMongoDBAdminBundle#162
• sonata-project/doctrine-orm-admin-bundle
  (will be 3.x):
  • Composer fixes and improvements SonataDoctrineORMAdminBundle#534
  • Fixing dependencies problem since 3.x-dev update SonataDoctrineORMAdminBundle#538
• sonata-project/doctrine-phpcr-admin-bundle (will be 2.x):
  • Composer improvements SonataDoctrinePhpcrAdminBundle#370
  • Fix composer dependencies SonataDoctrinePhpcrAdminBundle#371
  • tree-browser and resource-rest stable ETA SonataDoctrinePhpcrAdminBundle#373
• sonata-project/easy-extends-bundle
  (will be 2.x):
  • Composer improvements SonataEasyExtendsBundle#73
• sonata-project/ecommerce
  (will be ?):
• sonata-project/exporter
  (will be 1.x):
  • Composer improvements exporter#61
• sonata-project/formatter-bundle
  (will be 3.x):
  • Composer improvements SonataFormatterBundle#155
• sonata-project/google-authenticator
  (will be ?):
• sonata-project/intl-bundle
  (will be ?):
• sonata-project/markitup-bundle
  (will be ?):
• sonata-project/media-bundle
  (will be 3.x):
  • Composer fixes and improvements SonataMediaBundle#990
  • Remove doctrine managers SonataMediaBundle#494
• sonata-project/news-bundle
  (will be ?):
• sonata-project/notification-bundle
  (will be 3.x):
  • Composer improvements SonataNotificationBundle#169
• sonata-project/page-bundle
  (will be 3.x):
  • composer update fail since not supporting anymore 2.4 SonataPageBundle#634
  • Composer improvements and migrate for 3.0 SonataPageBundle#637
• sonata-project/propel-admin-bundle
  (will be ?):
• sonata-project/sandbox
  (will be ?):
• sonata-project/seo-bundle
  (will be 2.x):
  • Composer improve SonataSeoBundle#124
• sonata-project/sonata-composer
  (will be ?):
• sonata-project/timeline-bundle
  (will be ?):
• sonata-project/translation-bundle
  (will be 2.x):
  • Composer improvements SonataTranslationBundle#94
• sonata-project/user-bundle
  (will be ?):

Tagging

• Tag the v3.0.0 release. Rofl.

After Tagging

Related bundles stable releases

• [ ]

Misc

• Remove 2.0 -> 2.2 branches
• Move 2.3 to 2.x branch (just for history, no modification will be allowed).
• Create a 3.x branch => For minor releases
• Closes all PR concerning patch or minor modification with a message to tell user to rebase it on 3.x
• Do a "We are very glad that finally happenned!" tweet. 🎉

Am I missing something? Tell me! 👍

Tagged project

• core-bundle: 3.0.0
• block-bundle: 3.0.0
• admin-bundle: 3.0.0
• user-bundle: 3.0.0
• formatter-bundle: 3.0.0
• seo-bundle: 2.0.2
• classification-bundle: 3.0.0
• media-bundle: 3.0.0
• comment-bundle: 3.0.0
• page-bundle: 3.0.0
• news-bundle: 3.0.0

[Koc]

Would be great merge pending PRs first https://github.com/sonata-project/SonataAdminBundle/pulls?q=is%3Aopen+is%3Apr+milestone%3A2.4

[OskarStark]

ping @mvhirsch

[javiereguiluz]

@soullivaneuh what about signing the new v2.4.0 tag? Reference

[javiereguiluz]

@soullivaneuh another suggestion: prepare a "curated" changelog of the main features and bug fixes introduced by the new version.

[mvhirsch]

What about updating the documentation for 2.4?

[ju1ius]

Closes all PR concerning patch or minor modification with a message to tell user to rebase it on 2.x

@soullivaneuh I would say do not close right away. Label the issue as outdated, send a message to author telling authors to rebase and that the issue will be closed in a given time frame if they don't. And encourage them to close it by themselves if they don't intend to work on it any further (or the issue has been fixed since).

People tend to get angry when their PR/tickets receive no response for months, then is abruptly closed because the version changes.

[ju1ius]

@Koc I would say 👎 for merging #3258 in 2.4

The idea is great but there's a big responsiveness problem with the current top nav layout that can't be fixed in a BC way.
Basically, we first need to move the breadcrumb from the top bar to the main body, because a breadcrumb has by definition a potentially infinite length, and in a fixed appbar everything must fit on one line.
Then #3258 can be merged easilly, and make the breadcrumb component kick asses.

[soullivaneuh]

After discussing with @rande and @sonata-project/contributors we decided to not push a minor release but a major one.

So it will not be 2.4.0 but 3.0.0.

For some reasons:

• dev-master has already several BC breaking modifications that was merged (sigh)
• Pushing a major release would prevent other stable sonata bundle to auto-update to the new version and might be failed
• This will be the occasion to make a real separation between the old and the new versions management

I'll update the issue accordingly, with corresponding warns.

[soullivaneuh]

@soullivaneuh another suggestion: prepare a "curated" changelog of the main features and bug fixes introduced by the new version.

Yeah, I think we should create a new clear changelog starting from 3.0.

[soullivaneuh]

What about updating the documentation for 2.4?

2.4 -> 3.0

What do you mean?

[core23]

[ ] Move tickets from milestones to > 3.0 / 4.0

[soullivaneuh]

I would say do not close right away. Label the issue as outdated, send a message to author telling authors to rebase and that the issue will be closed in a given time frame if they don't.

@ju1ius I would see on a reverse way: people would reopen a pr if they want to continue.

In your way, we will have a lot of PR without continuing work but still open on the list. It's hard, but we will have a new and clean start.

ping @rande and @sonata-project/contributors for opinion.

People tend to get angry when their PR/tickets receive no response for months, then is abruptly closed because the version changes.

We just have to explain clearly why we are doing this. Sebastian did this for PHPUnit and it works great AFAIK.

For #3731 (comment), this is not related to this issue. Please comment on the related PR.

[soullivaneuh]

[ ] Move tickets from milestones to > 3.0 / 4.0

I think we will reset the milestones at all.

[ju1ius]

We just have to explain clearly why we are doing this. Sebastian did this for PHPUnit and it works great AFAIK.

Yes explaining is key.
I had the GNOME project in mind with their habit to automatically close every ticket that was submitted against an old version. More often than not the bug is still present and it leads to issues staying unresolved for years. It really pisses people off and discourage them to submit bugs and patches, which is a shame.

[soullivaneuh]

@ju1ius I understand your point of view. I still think we should do the closing way.

This is a kind of sacrifice, but we have to cleanup to have a good see of what to do for the future.

[soullivaneuh]

@Avtonom just see #3731 (comment) and #3732.

[Avtonom]

@soullivaneuh, thanks for the tip! I not immediately caught the depth changes.
How do I fix it?
sonata-project/classification-bundle 2.3.x-dev requires sonata-project/admin-bundle ~2.4 -> no matching package found

[soullivaneuh]

We are almost here! 🎉

All packages are now updated except 3 of them.

I closes this one in favor of dev-kit one: sonata-project/dev-kit#140

Thanks all for your support about this new adventure! 👯 😃