3.0.0 release todo #3731

Closed
Soullivaneuh opened this Issue Apr 20, 2016 · 51 comments

Projects

None yet
@Soullivaneuh
Member
Soullivaneuh commented Apr 20, 2016 edited

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 (#3732)
  • Change deprecation comment and warning from 3.0 to 4.0 and 2.4 to 3.0. (Thanks @greg0ire for remember) (#3733)
  • Change / reset milestones

Internal dependencies issues

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

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

@Soullivaneuh Soullivaneuh self-assigned this Apr 20, 2016
@Koc
Contributor
Koc commented Apr 20, 2016 edited
@OskarStark
Member

ping @mvhirsch

@javiereguiluz

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

@javiereguiluz
javiereguiluz commented Apr 20, 2016 edited

@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
Contributor
ju1ius commented Apr 20, 2016 edited

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
Contributor
ju1ius commented Apr 20, 2016 edited

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

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 changed the title from 2.4.0 release todo to 3.0.0 release todo Apr 20, 2016
@Soullivaneuh
Member

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

What about updating the documentation for 2.4?

2.4 -> 3.0

What do you mean?

@core23
Member
core23 commented Apr 20, 2016

[ ] Move tickets from milestones to > 3.0 / 4.0

@Soullivaneuh
Member

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
Member

[ ] Move tickets from milestones to > 3.0 / 4.0

I think we will reset the milestones at all.

@ju1ius
Contributor
ju1ius commented Apr 20, 2016 edited

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
Member

@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 Soullivaneuh added a commit to Soullivaneuh/SonataAdminBundle that referenced this issue Apr 20, 2016
@Soullivaneuh Soullivaneuh Good bye 2.4, welcome 3.x!
As decided on #3731
71f75b9
@Soullivaneuh Soullivaneuh added a commit that referenced this issue Apr 20, 2016
@Soullivaneuh Soullivaneuh Good bye 2.4, welcome 3.x! (#3732)
As decided on #3731
0a83abb
@Soullivaneuh Soullivaneuh added a commit to Soullivaneuh/SonataAdminBundle that referenced this issue Apr 20, 2016
@Soullivaneuh Soullivaneuh Replace deprecation messages and comment for 3.0
Old planned version was 2.4. It's now 3.0.

See why on #3731.
7937c3e
@Soullivaneuh Soullivaneuh added a commit that referenced this issue Apr 20, 2016
@Soullivaneuh Soullivaneuh Replace deprecation messages and comment for 3.0 (#3733)
Old planned version was 2.4. It's now 3.0.

See why on #3731.
2f26b5b
@Soullivaneuh
Member

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

@Avtonom
Avtonom commented Apr 20, 2016 edited

@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

@ju1ius
Contributor
ju1ius commented Apr 20, 2016 edited

@Avtonom Have you tried something like this (untested) ?

{
  "repositories": [
    {
      "type": "vcs",
      "url": "https://github.com/sonata-project/SonataAdminBundle"
    }
  ],
  "require": {
    "sonata-project/admin-bundle": "dev-master as 2.4"
  }
}

You might need to tweak the version alias, like maybe 2.4.x or 2.4.x-dev...

@Avtonom
Avtonom commented Apr 20, 2016 edited

Thank you!
+
"sonata-project/admin-bundle": "dev-master as 2.4",
"sonata-project/doctrine-orm-admin-bundle": "dev-master as 2.4",

@ju1ius
Contributor
ju1ius commented Apr 20, 2016 edited

@Soullivaneuh Maybe document this in the release note as a temporary solution until all bundles switch to the new release process ?

There will be a boatload of similar questions coming if the other bundles take time to catchup...

@Soullivaneuh
Member

@ju1ius I updated the post.

@core23
Member
core23 commented Apr 21, 2016

After creating the new 3.x branches, what will we do with the old 2.x versions? Leave them as they are or would we supply patches and security updates?

IMO we must support them too, because the users couldn't simply use the new versions and rely on the old one.

@Soullivaneuh
Member

@core23 The goal is to not support legacy branch and focus to only one to reduce the maintaining difficulty.

So globally no. After that, if someone have a very critical security issue to fix, we can consider that. But that's all, no patches will be accepted.

As I said, lot of people are already using dev-master because of compatibility with recent framework / library. Just see the download stats: https://packagist.org/packages/sonata-project/admin-bundle/stats#dev-master

This is also why I prefer to not merge new BC breaking PR until 3.0.

@dragosprotung dragosprotung added a commit to dragosprotung/SonataUserBundle that referenced this issue Apr 21, 2016
@dragosprotung dragosprotung Update version number for admin bundle
Version 2.4 does not exist anymore.
See sonata-project/SonataAdminBundle#3731 for details.
e5f74ef
@dragosprotung dragosprotung referenced this issue in sonata-project/SonataUserBundle Apr 21, 2016
Closed

Update version number for admin bundle #722

@muspelheim

@Soullivaneuh Hi, how much time need for migrate to 3.0 and stabilization?

@Soullivaneuh
Member

@muspelheim We hope to get a stable release of each bundle at beginning of may 2016.

@boltunoreh
boltunoreh commented Apr 21, 2016 edited

Since this time, if you're requiring sonata-project/admin-bundle 2.4.@dev on composer.json, you have to change to 3.0.@dev of dev-master@dev.

i think it should be

3.*@dev

not

3.0.*@dev

right?

@Soullivaneuh
Member

@boltunoreh indeed! Corrected, thanks!

@muspelheim

@Soullivaneuh How I can help in this?

@acrozes
acrozes commented Apr 21, 2016

For Internal dependencies issues:
Maybe add: sonata-project/SonataDoctrineMongoDBAdminBundle

Presently: sonata-project/doctrine-mongodb-admin-bundle dev-master requires sonata-project/admin-bundle ~2.3

@jmontoyaa

Dependency issue with pagebundle:

Problem 1
    - sonata-project/page-bundle dev-master requires sonata-project/admin-bundle ~2.4 -> satisfiable by sonata-project/admin-bundle[2.4.x-dev].
    - sonata-project/page-bundle dev-master requires sonata-project/admin-bundle ~2.4 -> satisfiable by sonata-project/admin-bundle[2.4.x-dev].
    - Can only install one of: sonata-project/admin-bundle[3.x-dev, 2.4.x-dev].
    - Installation request for sonata-project/admin-bundle 3.x-dev -> satisfiable by sonata-project/admin-bundle[3.x-dev].
    - Installation request for sonata-project/page-bundle dev-master -> satisfiable by sonata-project/page-bundle[dev-master].

@jmontoyaa
jmontoyaa commented Apr 22, 2016 edited

Maybe it will be a good idea to make sandbox based in 3.x

@Soullivaneuh
Member
Soullivaneuh commented Apr 22, 2016 edited

Please don't post your dependencies issues here.

See: #3731 (comment)

If you don't success to fix it, please open an issue on the concerned project.

Maybe it will be a good a day to make sandbox based in 3.x

It's planned.

@webdevilopers
Contributor

Currently Composer update fails:

        "friendsofsymfony/user-bundle": "1.3.*",
        "sonata-project/core-bundle": "dev-master",
        "sonata-project/admin-bundle": "3.*@dev",
        "sonata-project/doctrine-orm-admin-bundle": "dev-master",
        "sonata-project/cache-bundle": "dev-master",
        "sonata-project/datagrid-bundle": "dev-master",
        "sonata-project/user-bundle": "dev-master",
        "sonata-project/intl-bundle": "dev-master",
        "sonata-project/easy-extends-bundle": "dev-master",
        "sonata-project/doctrine-mongodb-admin-bundle": "dev-master",
        "sonata-project/translation-bundle": "dev-master",
    - sonata-project/translation-bundle dev-master requires sonata-project/admin-bundle ^2.3.0|~2.4@dev -> satisfiable by sonata-project/admin-bundle[2.4.x-dev, 2.3.x-dev].
    - sonata-project/translation-bundle dev-master requires sonata-project/admin-bundle ^2.3.0|~2.4@dev -> satisfiable by sonata-project/admin-bundle[2.4.x-dev, 2.3.x-dev].
    - Can only install one of: sonata-project/admin-bundle[3.x-dev, 2.4.x-dev].
    - Can only install one of: sonata-project/admin-bundle[3.x-dev, 2.3.x-dev].
    - Installation request for sonata-project/admin-bundle 3.*@dev -> satisfiable by sonata-project/admin-bundle[3.x-dev].
    - Installation request for sonata-project/translation-bundle dev-master -> satisfiable by sonata-project/translation-bundle[dev-master].

Other versions I tested fail with "sonata-project/doctrine-orm-admin-bundle". What is the current recommended setup?

@Soullivaneuh
Member
Soullivaneuh commented Apr 22, 2016 edited

@webdevilopers please read #3731 (comment). You have to use dependency aliases for now.

Please again, open issues on dedicated projects if you're still failing.

All other dependency issues messages posted here will be deleted.

@greg0ire
Contributor
greg0ire commented Apr 22, 2016 edited

What is the current recommended setup?

The current recommended setup is and always will be : stable branches. :trollface:

@core23 core23 referenced this issue in sonata-project/dev-kit Apr 22, 2016
Closed

Doc: FAQ for new version management #14

@greg0ire greg0ire referenced this issue in sonata-project/SonataDoctrineORMAdminBundle Apr 24, 2016
@Soullivaneuh Soullivaneuh Composer fixes and improves (#534)
* 3.x-dev
* Use new composer constraints notation
8004231
@jayesbe
jayesbe commented Apr 24, 2016

If anyone needs some insight into their own depedencies.. I just resolved mine with

        "sonata-project/admin-bundle" : "3.x-dev as 2.4",
        "sonata-project/doctrine-orm-admin-bundle" : "3.x-dev as 2.4",
        "sonata-project/user-bundle" : "^2.2",
        "sonata-project/media-bundle" : "2.4.x-dev",
        "sonata-project/classification-bundle" : "dev-master as 2.3",
        "sonata-project/datagrid-bundle" : "dev-master",

For the moment ;)

@pulzarraider
Member
pulzarraider commented Apr 25, 2016 edited

Remove 2.0 -> 2.2 branches

@Soullivaneuh this can't be done. It will cause to break projects that use the old Sonata version and we will probably lose something of the history.

@greg0ire
Contributor
greg0ire commented Apr 25, 2016 edited

Reminder : PLEASE DO NOT POST YOUR DEPENDENCIES ISSUES HERE, CREATE YOUR OWN ISSUE INSTEAD

@Soullivaneuh
Member

@pulzarraider why? 2.0 -> 2.2 branches has stable releases and those branches must not be maintained anymore.

@pulzarraider
Member

Branch 2.0 has no 2.0.* tag. We should release at least 2.0.0.

Branches 2.1 and 2.2 has some commits, that wasn't tagged yet after the latest release.
New versions 2.1.1, 2.2.13 should be released.

After this we should inform all users, that using the branch alias (e.g. "dev-2.2 as 2.2.x-dev") probably won't work and they should use just the stable releases, e.g. ~2.2 for projects using old Sonata.

@Soullivaneuh
Member
Soullivaneuh commented Apr 26, 2016 edited

Branch 2.0 has no 2.0.* tag. We should release at least 2.0.0.

Branches 2.1 and 2.2 has some commits, that wasn't tagged yet after the latest release.
New versions 2.1.1, 2.2.13 should be released.

Yeah in this case I will add releases. It's weird that this was not done before.

After this we should inform all users, that using the branch alias (e.g. "dev-2.2 as 2.2.x-dev") probably won't work and they should use just the stable releases, e.g. ~2.2 for projects using old Sonata.

The issue is right here for this. And using 2.2.x-dev is using a unstable branch, so breaking things can coming. The developer should know about that. ;-)

@Soullivaneuh Soullivaneuh referenced this issue in sonata-project/SonataUserBundle Apr 29, 2016
Closed

Symfony 3 compatibility #724

@Soullivaneuh
Member

@pulzarraider concerning branches and tags for admin-bundle:

Right now we should not accept any PR on 2.0 to 2.2 anymore.

Plan for soon:

After that, 2.x branch should be for bugfixes only and master for no BC breaking features.

After 3.0 stable, a 3.x branch will be created. So we will get:

  • 3.x for BC features and bugfix.
  • master (4.x) for BC breaking feature, deprecation removal etc.

And we will start following the new organization: #3053 🎉

@core23
Member
core23 commented May 1, 2016 edited

After 3.0 stable, a 3.x branch will be created. So we will get:

3.x for BC features and bugfix.
master (4.x) for BC breaking feature, deprecation removal etc.

After 3.0 stable, we remove the 2.x branch @Soullivaneuh? Or will we support bugfixes for 2.x and 3.x? Just to clearify your list...

@Soullivaneuh
Member

@core23 No I'm talking about removing 2.0, 2.1, 2.2 and 2.3 branches.

2.x will be created but just for history at the end.

The rule will always be the same, only two branch to maintain: master and the last stable branch (3.x at the end).

@SonataCI SonataCI removed the questions label May 2, 2016
@tim96
Contributor
tim96 commented May 2, 2016

We hope to get a stable release of each bundle at beginning of may 2016.

@Soullivaneuh do you need some help?

@Soullivaneuh
Member

@tim96 Not especially for this part thanks.

Actually we have a must have to validate, the changelog: sonata-project/dev-kit#8

After that, I think major releases will be push project by project, beginning by core-bundle... 😉

@pulzarraider
Member
pulzarraider commented May 3, 2016 edited

2.0: Absolutely not tag. I think this branch is old and not really used: https://packagist.org/packages/sonata-project/admin-bundle/stats#2.0.x-dev This can be removed.

@Soullivaneuh yes, probably no one is using it with composer, but it should be tagged so we don't lost any commit that was merged. I think that we should tag it is as 2.0.0.

@pulzarraider
Member

@Soullivaneuh thank you

@Soullivaneuh
Member

SonataCoreBundle 3.0.0 is out!

Tagging progress will be updated at the end of the main issue message: #3731

This was referenced May 26, 2016
@Soullivaneuh
Member

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! 👯 😃

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