There is no obvious way to deprecate a message schema #227
Labels
enhancement
New feature or request
Comments
|
CC @Zlopez |
abompard
added a commit
to abompard/fedora-messaging
that referenced
this issue
Oct 14, 2022
Fixes: fedora-infra#227, fedora-infra#247 Signed-off-by: Aurélien Bompard <[email protected]>
abompard
added a commit
to abompard/fedora-messaging
that referenced
this issue
Oct 14, 2022
Fixes: fedora-infra#227, fedora-infra#247 Signed-off-by: Aurélien Bompard <[email protected]>
abompard
added a commit
to abompard/fedora-messaging
that referenced
this issue
Oct 14, 2022
Fixes: fedora-infra#227, fedora-infra#247 Signed-off-by: Aurélien Bompard <[email protected]>
abompard
added a commit
that referenced
this issue
Oct 14, 2022
Fixes: #227, #247 Signed-off-by: Aurélien Bompard <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When a message schema must be changed in a backwards-incompatible way, a new class & schema must be written, but there is no obvious way nor helper to mark the old class as deprecated. It's always possible to raise a
DeprecationWarningin the constructor, but the sender app will get that warning for the duration of the transition period, which is not ideal.There could be a class attribute that the
get_message()function would test for and raise aDeprecationWarningwhen true, it would only raise the warning when the message is read from the broker, not produced.The text was updated successfully, but these errors were encountered: