New Guava compatibility policy
Chris Povirk
New policy: For the indefinite future, we won't remove APIs (except those annotated @Beta). This replaces our old policy, which let us remove an API 2 years after deprecating it.
More precisely, we won't make any kind of binary-incompatible change (again, except to @Beta APIs). For brevity, I'll say just "remove" in this doc. We use the more precise phrasing in the official policy.
Why the change?
The old policy made it harder for libraries to depend on Guava (unless they relocated it):
If a library used Guava, its owners had to be prepared to regularly release new versions.
If a project used libraries that used Guava, its owners had to be prepared to regularly update their versions of all those libraries.
These drawbacks are not new, but they've become a bigger problem over time, as more libraries come to depend on Guava and some old libraries stop releasing new versions.
What about @Beta?
We'll continue to occasionally remove @Beta APIs. Our policy permits us to remove them at any time, but, when practical, we'll continue to deprecate @Beta APIs at least 3 months in advance of removal. Also, we'll soon release a compile-time checker to help libraries ensure they don't use @Beta APIs.
When does this take effect?
Immediately:
Even if an API is already @Deprecated, we no longer plan to delete it (unless it's @Beta).
Technically, there is one exception: We deprecated the CharMatcher constants back when they were @Beta. Then we removed @Beta from the class. Because these methods were never present as non-@Deprecated, non-@Beta APIs, and because they are expensive to initialize on Android, we'll still remove them.
In fact, neither Guava 22 nor Guava 23 removed APIs (except @Beta), so in effect, the policy applies back to APIs present in Guava 21.0, released January 2017.
How long will it last?
We have no plans to start removing things again, but officially, we're leaving our options open in case of surprises (like, say, a serious security problem).