mirror of
https://github.com/doctrine/orm.git
synced 2026-03-23 22:42:18 +01:00
BC break from 2.14.1 to 2.14.2 Using (deprecated) short namespace alias #7131
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @PhilETaylor on GitHub (Apr 13, 2023).
BC Break Report
Summary
YES I UNDERSTAND that the relied upon feature (short namespace alias) is deprecated BUT upgrading in a MINOR release from 2.14.1 to 2.14.2 should not break an app that was working fine in 2.14.1 - that goes against SEMVER
Previous behavior
No error messages when using doctrine/orm 2.14.1
Current behavior
after composer update to doctrine/orm 2.14.2 from 2.14.1 - a minor release, now getting app crashes due to relying on deprecated features (I know I know)
This is caused by now throwing Exceptions where no exceptions were previously thrown (because of a bug) https://github.com/doctrine/orm/pull/10489
How to reproduce
The related package is https://github.com/j-guyon/CommandSchedulerBundle which is a 3 year old release. Yes I know I know I know... but still, a minor release of doctrine/orm should not have breaking changes
@greg0ire commented on GitHub (Apr 13, 2023):
You are confusing MINOR and PATCH. 2.14.2 is not a minor release, it is a patch release. BUT. Short aliases are not a feature of
doctrine/orm, they are a feature ofdoctrine/persistence, which means that if you rely on them, you (or rather,jmose/command-scheduler-bundle) should havedoctrine/persistencein composer.json, and you should still be usingdoctrine/persistence2 instead ofdoctrine/persistence3. If that were still the case, you would get a deprecation, not a crash.A solution for you personally can be to downgrade to
doctrine/persistence2, and address the issue when you have the time.OK, there were no error messages, but was it working? I believe it either didn't, or worked by accident. If you were using persistence 3 at the time, then you were not using short aliases.
To fully understand the issue, it would be great to have a stack trace
@PhilETaylor commented on GitHub (Apr 13, 2023):
In my defence it was 4am (now 8am) zzz
Personally I just removed the bundle and replaced with zenstruck scheduler within 20 mins and deployed that to production already - it's a far superior product anyway
You can close this as it doesn't really affect me now but the fact remains updating a PATCH version broke otherwise working (albeit old bundle) code from working
@greg0ire commented on GitHub (Apr 13, 2023):
As I said, I suspect it wasn't actually working.
@PhilETaylor commented on GitHub (Apr 13, 2023):
The scheduler has been running every min of every day for almost 10 years. It's the backbone of a service that has made me several million pounds... but hey, it's fixed now and I can go to bed.
Off topic: Also, when someone sponsors you $100 it would be nice, the most minimal thing to do, is to acknowledge it... but you are not alone, many developers don't even acknowledge GitHub sponsorships - ah well.
@greg0ire commented on GitHub (Apr 13, 2023):
Maybe it was working by accident, but I cannot see how if you were using persistence 3, which does not support short aliases since 3.0: https://github.com/doctrine/persistence/blob/3.1.x/UPGRADE.md#bc-break-removed-support-for-short-namespace-aliases
Or maybe you're not using them at all, and there is a call to
addEntityNamespacewith a namespace that you don't use? We will never know since you neglected to provide a stack trace.Regarding the $100, I must admit I noticed them. In fact we all did, and wondered what was up with you. I thought it was maybe your way to apologize, and they are the reason I decided to help you figure this out today. Are you going to make me regret it? Let's not find out and lock this, again.