Skip to content
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

Allow Symfony 4 #6733

Merged
merged 1 commit into from
Oct 23, 2017
Merged

Allow Symfony 4 #6733

merged 1 commit into from
Oct 23, 2017

Conversation

fabpot
Copy link
Member

@fabpot fabpot commented Sep 27, 2017

@nicolas-grekas added support for Symfony 4.0, but only on the master branch, which is yet to be released. As Symfony 4 will start to be in beta really soon now (next week), having support for it in Doctrine 2.5 is critical.

I know that's a lot to ask, but is it possible to merge this PR and release 2.5.12?

Thank you a lot for your help on this one.

@Ocramius
Copy link
Member

Ocramius commented Sep 28, 2017 via email

@fabpot
Copy link
Member Author

fabpot commented Sep 28, 2017

Is it really a new feature? Any ETA for the next Doctrine version? Not merging this pull request means no Doctrine for Symfony 4. Anybody else able to work with us on this issue before you have time?

@fabpot
Copy link
Member Author

fabpot commented Sep 28, 2017

Note that the only change is about the console component, nothing core to Doctrine.

@Ocramius
Copy link
Member

I might be able to do the release on Sunday, since I'm commuting ~10h via 🚋.

It must be clear that ORM 2.5 will not have this addition though, sorry.

@jwage
Copy link
Member

jwage commented Sep 28, 2017

@fabpot When are you planning to release Symfony 4.0?

@weaverryan
Copy link
Contributor

I believe this weekend or very early next week. Feature freeze is technically Saturday.

@jwage
Copy link
Member

jwage commented Sep 29, 2017

@Ocramius why can we not include this in a 2.5.x release? I am 👍 unless I hear a compelling reason not to. /cc @beberlei

@Ocramius
Copy link
Member

Ocramius commented Oct 2, 2017

@jwage the scenario is quite simple, and it is the reason for never updating dependencies in patch releases:

  1. somebody requires "doctrine/orm": "2.5.*"
  2. that somebody uses Symfony\Component\* in their codebase, has no direct dependency to it though (their mistake, but that's how it is)
  3. run composer update and things break

I'm fine with bumping in a minor release, not in a patch release, since any environment must always be able to upgrade patch releases at any time due to possible security releases.

@alcaeus
Copy link
Member

alcaeus commented Oct 2, 2017

@Ocramius

that somebody uses Symfony\Component\* in their codebase, has no direct dependency to it though (their mistake, but that's how it is)

That would most likely blow up in their face regardless of a patch or minor release: The current version constraint for doctrine/orm in the Symfony Standard Edition is ^2.5 and it has been that (or ~2.5, which is equivalent) since Symfony 2.3.something. Thus, once we release ORM 2.6 with such a change it would blow up anyways.

TBH, I wouldn't consider that a problem: if you use something through an implicit dependency you shouldn't be surprised if that implicit dependency is no longer filled. Also, since we'd add |~4.0 to the Symfony constraints, any package with a hard requirement on a specific Symfony version would still continue to work. All in all, I believe it's ok merging this into 2.5, not only 2.6.

@Ocramius
Copy link
Member

Ocramius commented Oct 2, 2017

@alcaeus I'm fine with changing this decision if there's enough consensus and this kind of crash is just removed from the BC compliance issues on our side: just need to make that very clear.

Just to add to #6733 (comment), the removal of supported dependency versions should absolutely never happen (unrelated to this issue). The addition of a range is still a risk, IMO.

@alcaeus
Copy link
Member

alcaeus commented Oct 2, 2017

I agree on the BC compliance issue, but then I'd always put blame on the user if an implicit dependency blows up in their face.

@Ocramius
Copy link
Member

Ocramius commented Oct 2, 2017

I'd always put blame on the user if an implicit dependency blows up in their face

I'm fine with this stance. If nobody has an issue with it, then we can backport to 2.5 too.

@jwage
Copy link
Member

jwage commented Oct 2, 2017

👍 Sounds good. Thanks!

@dunglas
Copy link
Contributor

dunglas commented Oct 23, 2017

I'm fine with this stance. If nobody has an issue with it, then we can backport to 2.5 too.

Looks reasonable.

Currently trying to install Doctrine or any package depending of Doctrine with Symfony 4 (already in beta) result in the following error:

  Problem 1
    - doctrine/orm v2.5.9 requires symfony/console ~2.5|~3.0 -> satisfiable by symfony/console[2.5.x-dev, 2.6.x-dev, 2.7.x-dev, 2.8.x-dev, 3.0.x-dev, 3.1.x-dev, 3.2.x-dev, 3.3.x-dev, 3.4.x-dev, v2.5.0, v2.5.0-BETA1, v2.5.0-BETA2, v2.5.0-RC1, v2.5.1, v2.5.10, v2.5.11, v2.5.12, v2.5.2, v2.5.3, v2.5.4, v2.5.5, v2.5.6, v2.5.7, v2.5.8, v2.5.9, v2.6.0, v2.6.0-BETA1, v2.6.0-BETA2, v2.6.1, v2.6.10, v2.6.11, v2.6.12, v2.6.13, v2.6.2, v2.6.3, v2.6.4, v2.6.5, v2.6.6, v2.6.7, v2.6.8, v2.6.9, v2.7.0, v2.7.0-BETA1, v2.7.0-BETA2, v2.7.1, v2.7.10, v2.7.11, v2.7.12, v2.7.13, v2.7.14, v2.7.15, v2.7.16, v2.7.17, v2.7.18, v2.7.19, v2.7.2, v2.7.20, v2.7.21, v2.7.22, v2.7.23, v2.7.24, v2.7.25, v2.7.26, v2.7.27, v2.7.28, v2.7.29, v2.7.3, v2.7.30, v2.7.31, v2.7.32, v2.7.33, v2.7.34, v2.7.35, v2.7.4, v2.7.5, v2.7.6, v2.7.7, v2.7.8, v2.7.9, v2.8.0, v2.8.0-BETA1, v2.8.1, v2.8.10, v2.8.11, v2.8.12, v2.8.13, v2.8.14, v2.8.15, v2.8.16, v2.8.17, v2.8.18, v2.8.19, v2.8.2, v2.8.20, v2.8.21, v2.8.22, v2.8.23, v2.8.24, v2.8.25, v2.8.26, v2.8.27, v2.8.28, v2.8.3, v2.8.4, v2.8.5, v2.8.6, v2.8.7, v2.8.8, v2.8.9, v3.0.0, v3.0.0-BETA1, v3.0.1, v3.0.2, v3.0.3, v3.0.4, v3.0.5, v3.0.6, v3.0.7, v3.0.8, v3.0.9, v3.1.0, v3.1.0-BETA1, v3.1.0-RC1, v3.1.1, v3.1.10, v3.1.2, v3.1.3, v3.1.4, v3.1.5, v3.1.6, v3.1.7, v3.1.8, v3.1.9, v3.2.0, v3.2.0-BETA1, v3.2.0-RC1, v3.2.0-RC2, v3.2.1, v3.2.10, v3.2.11, v3.2.12, v3.2.13, v3.2.2, v3.2.3, v3.2.4, v3.2.5, v3.2.6, v3.2.7, v3.2.8, v3.2.9, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1] but these conflict with your requirements or minimum-stability.

Not really a good user experience.

@janit
Copy link

janit commented Oct 23, 2017

+1 for backporting to 2.5 if possible, especially as I'm not sure when 2.6 would be landing.

@JulianTenschert
Copy link

👍 Backporting to 2.5 would be great. Thanks!

@psampaz
Copy link

psampaz commented Oct 23, 2017

👍 for backporting to 2.5

Copy link
Member

@jwage jwage left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will create the tag for this soon.

@jwage jwage merged commit 35a579e into doctrine:2.5 Oct 23, 2017
@janit
Copy link

janit commented Oct 23, 2017

Cool, I can confirm it works now with Symfony 4. There is still an issue with the integration bundle and Symfony 4, but it is just pending on a new release. Ticket here: doctrine/DoctrineBundle#720

@lcobucci lcobucci added this to the 2.5.12 milestone Nov 24, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants