-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
Conflict symfony/validator 7.0 in symfony/doctrine-bridge 6.3 #51630
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
Conversation
Hey! Thanks for your PR. You are targeting branch "6.3" but it seems your PR description refers to branch "6.3 for features / 5.4, or 6.3 for bug fixes". Cheers! Carsonbot |
0e3cee7
to
18cdf5f
Compare
@@ -63,7 +63,7 @@ | |||
"symfony/proxy-manager-bridge": "<4.4.19", | |||
"symfony/security-bundle": "<5", | |||
"symfony/security-core": "<5.3", | |||
"symfony/validator": "<5.4.25|>=6,<6.2.12|>=6.3,<6.3.1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if it would better to add a conflict to symfony/validator
7.0
as adding a conflict after a release in this case (5.4 and 6.3) will composer maybe just install a old version of the doctrine-bridge
e.g. (5.4.28 or 6.3.4) without that conflict and then still run into the same error 🤔.
But it feels strange to add a conflict to symfony/validator
as it has not even a optional dependency to the bridge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should add this conflict rule here (where it is legitimate), but we should also add it in validator 7.0 to avoid the issue of installing validator 7.0 and an outdated doctrine-bridge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would work I think. @nicolas-grekas what do you think about that?
This won't work: previous versions don't have the conflict so that composer might decide to install them instead of the latest 6.3. |
@nicolas-grekas just removing the return type would fix compat with 7.0. But there is no conflict rule with 8.0 or 9.0 either so this cannot be the proper solution unless we avoid adding that return type forever. |
We bump deps in major version so that this guards naturally against such situations. Also, while we do seek for cross-majors compat between components, we don't between three majors. I would just add the return type in 8.0 and tell ppl that encounter the situation they have to update (6.3 will be EOLed since a long time) since this highly theoretical to me. |
@nicolas-grekas this is a case of an optional dependency between components, for which our existing usages of conflict rules only restrict one side of the range (equivalent to use an |
Sure, but still :) combining validator v8 with the bridge v6.3 should be an unsupported situation IMHO so I wouldn't care. |
For future we maybe could make sure to add all |
We never do that AFAIK: making a component aware of a bridge (or if we do, that should be exceptionnal). That's broken package principles to me. |
@nicolas-grekas we already made that in the past for conflict rules to handle the fact that we could not retro-actively add an upper bound to an optional dependency that was defined with a conflict rule allowing all future versions. The way to avoid that (to respect package principles) would be that all our optional dependencies should forbid future major versions of that dependency with a conflict rule until we can ensure compatibility (basically avoiding unbounded optional dependencies) |
That'd be too complex to manage I fear. I'm still up for the simple solution: revert the return type on v7, add it on v8 and don't care about what's going to be theoretical issue in 2/3 years. Alternatively, we could add the conflict in validator v7, but only that then. That's not my preference thought as it "pollutes" the deps of v7, while the point of a major is also to cleanup those things from the past. |
@@ -63,7 +63,7 @@ | |||
"symfony/proxy-manager-bridge": "<4.4.19", | |||
"symfony/security-bundle": "<5", | |||
"symfony/security-core": "<5.3", | |||
"symfony/validator": "<5.4.25|>=6,<6.2.12|>=6.3,<6.3.1" | |||
"symfony/validator": "<5.4.25|>=6,<6.2.12|>=6.3,<6.3.1,>=7.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"symfony/validator": "<5.4.25|>=6,<6.2.12|>=6.3,<6.3.1,>=7.0" | |
"symfony/validator": "<5.4.25|>=6,<6.2.12|>=6.3,<6.3.1|>=7.0" |
I feel like y'all prefer the conflict-based approach, see #51634 |
…nicolas-grekas) This PR was merged into the 7.0 branch. Discussion ---------- [Validator] Make v7 conflict with doctrine-bridge < v7 | Q | A | ------------- | --- | Branch? | 7.0 | Bug fix? | no | New feature? | no | Deprecations? | no | Tickets | - | License | MIT | Doc PR | - Instead of #51630 Commits ------- 6b3e251 [Validator] Make v7 conflict with doctrine-bridge < v7
Currently it is possible to have
doctrine-bridge
6.3 andvalidator
7.0 installed which ends in the following error:The conflict can be removed then on the 7.0 branch where the
: void
return type is added.Tested it also appears on 5.4 branch so conflict there would also be good, rebased so to 5.4.
You maybe ask why
symfony/doctrine-bridge
was in my example not on7.0
. If a project still is usingdoctrine/persistence
2.0
instead of3.0
it can not update the bridge to 6.4 or 7.0. So it could be a common error, to avoid this I suggest to add a conflict.