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
Rework the deprecation process #199
Comments
@MGaetan89 I think we can keep the current deprecated methods as it's a safe approach to reduce the affects to the minimum. But we don't follow them correctly as we often remove deprecated methods lately to get a better compatibility issues. It's not easy to bump to Robolectric 5.0.0 if you see Robolectric's GitHub package system, and there was a 5.0.0 alpha with multiple breaking changes. So we might remove some obsoleted APIs in 4.x.x. |
But we can discuss whether to delay the real deletion version after it is marked by Deprecated. |
@MGaetan89 it is often difficult to remove deprecated methods. For instance, the legacy looper mode has been deprecated for years, but there are many of tests at Google that use it. This is because it is sometimes nontrivial to convert tests to use PAUSED looper mode, and sometimes code gets into maintenance mode and people don't actively invest in cleaning it up. |
I started to understand as much by contributing on various part of the project 🙂 |
Based on the discussion in robolectric/robolectric#8810, I think it would make sense to rework the Deprecations and Backwards Compatibility section of the documentation.
Instead of removing deprecated code in the next minor version, they are removed based on usages (from what I understood).
robolectric.github.io/contributing.md
Line 63 in dc970c5
Maybe a more streamlined approach could be that anything deprecated in version x.y.z will be removed in (x + 1).0.0. What do you think?
We could then updated all the current deprecated code to say they they will be removed in Robolectric 5.0.0.
The text was updated successfully, but these errors were encountered: