Sonataadminbundle: 3.0.0 release todo

Created on 20 Apr 2016  路  51Comments  路  Source: sonata-project/SonataAdminBundle

Issue updated since https://github.com/sonata-project/SonataAdminBundle/issues/3731#issuecomment-212530813:
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 https://github.com/sonata-project/SonataAdminBundle/issues/3731#issuecomment-212636270.

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

  • [x] Change 2.4.x-dev to 3.x-dev on composer.json (#3732)
  • [x] 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

  • [x] Tag the v3.0.0 release. Rofl.

    After Tagging

Related bundles stable releases

  • [ ]

    Misc

  • [x] Remove 2.0 -> 2.2 branches

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

Am I missing something? Tell me! :+1:

Tagged project

critical in progress
Source
picture soullivaneuh
👍11 🎉1

Most helpful comment

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 ;)

picture jayesbe on 24 Apr 2016
👍9 ❤1

All 51 comments

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

Koc picture Koc on 20 Apr 2016

ping @mvhirsch

OskarStark picture OskarStark on 20 Apr 2016

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

javiereguiluz picture javiereguiluz on 20 Apr 2016
👍1

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

javiereguiluz picture javiereguiluz on 20 Apr 2016

What about updating the documentation for 2.4?

mvhirsch picture mvhirsch on 20 Apr 2016

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 picture ju1ius on 20 Apr 2016
👍1

@Koc I would say :-1: 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.

ju1ius picture ju1ius on 20 Apr 2016

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 picture soullivaneuh on 20 Apr 2016

@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 picture soullivaneuh on 20 Apr 2016

What about updating the documentation for 2.4?

2.4 -> 3.0

What do you mean?

soullivaneuh picture soullivaneuh on 20 Apr 2016

[ ] Move tickets from milestones to > 3.0 / 4.0

core23 picture core23 on 20 Apr 2016

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 https://github.com/sonata-project/SonataAdminBundle/issues/3731#issuecomment-212509707, this is not related to this issue. Please comment on the related PR.

soullivaneuh picture soullivaneuh on 20 Apr 2016

[ ] Move tickets from milestones to > 3.0 / 4.0

I think we will reset the milestones at all.

soullivaneuh picture soullivaneuh on 20 Apr 2016

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.

ju1ius picture ju1ius on 20 Apr 2016

@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 picture soullivaneuh on 20 Apr 2016
👍2

@Avtonom just see https://github.com/sonata-project/SonataAdminBundle/issues/3731#issuecomment-212530813 and #3732.

soullivaneuh picture soullivaneuh on 20 Apr 2016
😄1

@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

Avtonom picture Avtonom on 21 Apr 2016

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

ju1ius picture ju1ius on 21 Apr 2016
👍2

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

Avtonom picture Avtonom on 21 Apr 2016
🎉5

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

ju1ius picture ju1ius on 21 Apr 2016

@ju1ius I updated the post.

soullivaneuh picture soullivaneuh on 21 Apr 2016
👍1

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.

core23 picture core23 on 21 Apr 2016

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

soullivaneuh picture soullivaneuh on 21 Apr 2016
👍1

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

muspelheim picture muspelheim on 21 Apr 2016

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

soullivaneuh picture soullivaneuh on 21 Apr 2016

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?

boltunoreh picture boltunoreh on 21 Apr 2016

@boltunoreh indeed! Corrected, thanks!

soullivaneuh picture soullivaneuh on 21 Apr 2016

@Soullivaneuh How I can help in this?

muspelheim picture muspelheim on 21 Apr 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

acrozes picture acrozes on 22 Apr 2016

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 picture jmontoyaa on 22 Apr 2016

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

jmontoyaa picture jmontoyaa on 22 Apr 2016

Please don't post your dependencies issues here.

See: https://github.com/sonata-project/SonataAdminBundle/issues/3731#issuecomment-212636270

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.

soullivaneuh picture soullivaneuh on 22 Apr 2016
👍5

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?

webdevilopers picture webdevilopers on 22 Apr 2016

@webdevilopers please read https://github.com/sonata-project/SonataAdminBundle/issues/3731#issuecomment-212636270. 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.

soullivaneuh picture soullivaneuh on 22 Apr 2016
😄1

What is the current recommended setup?

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

greg0ire picture greg0ire on 22 Apr 2016
😄4 🎉1

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 ;)

jayesbe picture jayesbe on 24 Apr 2016
👍9 ❤1

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.

pulzarraider picture pulzarraider on 25 Apr 2016

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

greg0ire picture greg0ire on 25 Apr 2016
👍1

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

soullivaneuh picture soullivaneuh on 25 Apr 2016

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.

pulzarraider picture pulzarraider on 26 Apr 2016

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 picture soullivaneuh on 26 Apr 2016

@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: https://github.com/sonata-project/SonataAdminBundle/issues/3053 :tada:

soullivaneuh picture soullivaneuh on 1 May 2016

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

core23 picture core23 on 1 May 2016

@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).

soullivaneuh picture soullivaneuh on 1 May 2016
👍1

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

@Soullivaneuh do you need some help?

tim96 picture tim96 on 2 May 2016

@tim96 Not especially for this part thanks.

Actually we have a must have to validate, the changelog: https://github.com/sonata-project/dev-kit/issues/8

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

soullivaneuh picture soullivaneuh on 2 May 2016

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 picture pulzarraider on 3 May 2016

@pulzarraider https://github.com/sonata-project/SonataAdminBundle/releases/tag/2.0.0

soullivaneuh picture soullivaneuh on 3 May 2016

@Soullivaneuh thank you

pulzarraider picture pulzarraider on 3 May 2016

SonataCoreBundle 3.0.0 is out!

Tagging progress will be updated at the end of the main issue message: https://github.com/sonata-project/SonataAdminBundle/issues/3731

soullivaneuh picture soullivaneuh on 6 May 2016
🎉1

We are almost here! :tada:

All packages are now updated except 3 of them.

I closes this one in favor of dev-kit one: https://github.com/sonata-project/dev-kit/issues/140

Thanks all for your support about this new adventure! :dancers: :smiley:

soullivaneuh picture soullivaneuh on 7 Jun 2016
🎉3
Was this page helpful?
0 / 5 - 0 ratings

Related issues

vazgen picture vazgen  路  4Comments
Chrysweel picture Chrysweel  路  3Comments
core23 picture core23  路  4Comments
core23 picture core23  路  3Comments
jenyak picture jenyak  路  3Comments