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

Dynamically switching the deprecation warning instance to be raised (i.e. SevereDeprecationWarning) #655

Open
zhukovgreen opened this issue Aug 11, 2020 · 3 comments

Comments

@zhukovgreen
Copy link
Contributor

zhukovgreen commented Aug 11, 2020

btw I got an idea, what might compliment our deprecation feature. If the period of the deprecation is close to expire, we might dynamically switch the deprecation warning instance to be raise (i.e. SevereDeprecationWarning) and set in pytest.ini to fail tests when this SevereDeprecationWarning captured

Originally posted by @zhukovgreen in https://github.com/oamg/leapp/diffs

@deprecated(since="2021-06-01", message="Some message")
class SomeModel:
    pass

Let's assume some user has in-house actor, which uses SomeModel. And this actor covered by tests.
In this case, before 2021-06-01 the test will be passing, just warnings will be notified, but after 2021-06-01 tests will start failing.

Nothing more - the actor will still work, only tests will fail. If there aren't tests, then no warnings and no failures at all (until we really remove the model at least).

This mechanism could also allow us to trace suppressed deprecated warnings which have expired deprecation notice (our tests will start failing). And we would need to update the date.

@zhukovgreen zhukovgreen self-assigned this Aug 11, 2020
@pirat89
Copy link
Member

pirat89 commented Aug 11, 2020

Doesn't that mean, that after the 6m period, users will be in a similar situation as in case we remove the functionality? Keep in mind that when we deprecate something, for user it could mean they have in bed scenario just 1month to fix the code. That is not so good I guess. For users it should be ~6month since they receive the product. That's why we are not telling that we will remove the functionality right after the 6m period. We want to keep the original functionality until we remove it.

@zhukovgreen
Copy link
Contributor Author

zhukovgreen commented Aug 11, 2020

@pirat89 Better to show the idea by example

@deprecated(since="2021-06-01", message="Some message")
class SomeModel:
    pass

Let's assume some user has in-house actor, which uses SomeModel. And this actor covered by tests.
In this case, before 2021-06-01 the test will be passing, just warnings will be notified, but after 2021-06-01 tests will start failing.

Nothing more - the actor will still work, only tests will fail. If there aren't tests, then no warnings and no failures at all (until we really remove the model at least).

This mechanism could also allow us to trace suppressed deprecated warnings which have expired deprecation notice (our tests will start failing). And we would need to update the date.

@pirat89
Copy link
Member

pirat89 commented Aug 11, 2020

To be honest, I do not know. I've got your idea, but I am not sure whether it's good or wrong way. It's not common to do anything like that in projects, so I am not so much happy about anything like that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants