From sflaniga at redhat.com Tue Oct 3 04:59:13 2017 From: sflaniga at redhat.com (Sean Flanigan) Date: Tue, 3 Oct 2017 14:59:13 +1000 Subject: [zanata-devel] Fwd: New Guava compatibility policy In-Reply-To: References: Message-ID: This is good news. We're currently using Guava 21 for server code, so this means any Guava APIs we're currently using should stick around indefinitely. And RichFaces seems to be compatible with Guava 21's API, so RichFaces should be safe from Guava breakage like https://issues.jboss.org/browse/RF-13247. ---------- Forwarded message ---------- From: 'Chris Povirk' via Guava Announce Date: 30 September 2017 at 04:48 Subject: New Guava compatibility policy To: guava-discuss 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- at Deprecated, non- at 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). -- You received this message because you are subscribed to the Google Groups "Guava Announce" group. To unsubscribe from this group and stop receiving emails from it, send an email to guava-announce+unsubscribe at googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/ms gid/guava-announce/CAEvq2np26f2Hw0SW1KRkxyq4f3c3eYqLfWm0LHki U2TkfPDvOA%40mail.gmail.com . For more options, visit https://groups.google.com/d/optout. -- Sean Flanigan Principal Software Engineer Globalisation Tools Engineering Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: