Add conflict rule for Monolog 2 #32469
Conversation
derrabus
changed the title
|
Not sure this works: this won't prevent composer from selecting any already released version. |
|
Yeah this sounds like it'll introduce more confusion than anything really. |
|
I'm sure it'll work, but I might have tried to take a sledgehammer to crack a nut here. 🤔 |
|
@derrabus can you please resubmit this PR? We're going to merge it anyway. |
|
Reopened. |
derrabus
force-pushed
the
improvement/block-monolog-2
branch
from
c21cdb3 to
d53b91a
Compare
|
Thank you @derrabus. |
This PR was merged into the 3.4 branch. Discussion ---------- Add conflict rule for Monolog 2 | Q | A | ------------- | --- | Branch? | 3.4 | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #27857, symfony/monolog-bundle#300 | License | MIT | Doc PR | N/A Depending on the monorepo has been best practice in Symfony 3 and is discouraged but still possible in Symfony 4. If the Symfony Standard Edition was used to bootstrap the application, Monolog is installed as dependency of the MonologBundle. Thus, if we released a MonologBundle that indicates compatibility with Monolog 2, those application would be bumped to Version 2 although MonologBridge 3.4 is not ready for it. The goal is to prevent this from happening. This PR adds a conflict rule for Monolog 2 to the 3.4 branch. Assuming this gets merged before the next Symfony releases (3.4.30, 4.2.11, 4.3.3), my plan would be to bump MonologBundle's dependencies like this: ```diff "require": { - "monolog/monolog": "~1.22", - "symfony/monolog-bridge": "~3.4|~4.0" + "monolog/monolog": "~1.22|~2.0", + "symfony/monolog-bridge": "^3.4.30|~4.2.11|^4.3.3|^5.0" } ``` If I'm not mistaken, this should remove any possible combination of Symfony 3/4 and Monolog 2. Projects depending on individual packages instead of the monorepo should be safe already because MonologBridge 3.x/4.x locks Monolog at version 1. Commits ------- d53b91a Add conflict rule for Monolog 2.
No, I think you were onto something. Had this PR been merged in July, a lot of people-hours around the world could have been put to better use than to research why yet again |
|
If people would test their applications with the next to come stable releases of their dependencies, they could report issues before the actual release and issues could be detected soon enough. |
|
You mean people should set up an automated CI task to change all Composer dependencies to the dev-branch of the version they're on and run tests nightly? I would expect that for a new major or minor version but why should I assume that a point release on an LTS version breaks anything?! I expect a project I'm maintaining and not actively working on, that we decided to put on a LTS version because of the BC promise, to simply work. (I know, we've had this discussion before about "We fixed a glitch" in a point release... 😉) And this is not about the amount of work required to rectify the problem, it's about making everyone insecure about the BC promise. What used to be a "oh, I can just |
|
The BC promise does not promise that we don't make mistakes. Also, Monolog 2 will not have popped up by just updating to the next patch release. You would also have to update MonologBundle from 3.4 or lower to 3.5. |
|
You are correct, it wasn't the point release of Symfony. It was the minor version release of MonologBundle which we require with Either way, I will probably invest some time in your suggestion to identify such problems beforehand and contribute to solving them. So next time it won't just be @derrabus doubting himself months before this hits "the streets". 😉 Peace! |
Depending on the monorepo has been best practice in Symfony 3 and is discouraged but still possible in Symfony 4. If the Symfony Standard Edition was used to bootstrap the application, Monolog is installed as dependency of the MonologBundle. Thus, if we released a MonologBundle that indicates compatibility with Monolog 2, those application would be bumped to Version 2 although MonologBridge 3.4 is not ready for it. The goal is to prevent this from happening.
This PR adds a conflict rule for Monolog 2 to the 3.4 branch. Assuming this gets merged before the next Symfony releases (3.4.30, 4.2.11, 4.3.3), my plan would be to bump MonologBundle's dependencies like this:
"require": { - "monolog/monolog": "~1.22", - "symfony/monolog-bridge": "~3.4|~4.0" + "monolog/monolog": "~1.22|~2.0", + "symfony/monolog-bridge": "^3.4.30|~4.2.11|^4.3.3|^5.0" }If I'm not mistaken, this should remove any possible combination of Symfony 3/4 and Monolog 2.
Projects depending on individual packages instead of the monorepo should be safe already because MonologBridge 3.x/4.x locks Monolog at version 1.