[zanata-devel] Fwd: New Guava compatibility policy

[Sean Flanigan]

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 <guava-announce at googlegroups.com>
Date: 30 September 2017 at 04:48
Subject: New Guava compatibility policy
To: guava-discuss <guava-discuss at googlegroups.com>


New policy: For the indefinite future, we won't remove APIs (except those
annotated @Beta
<http://google.github.io/guava/releases/snapshot/api/docs/com/google/common/annotations/Beta.html>).
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
<https://github.com/google/guava#important-warnings>.

Why the change?

The old policy made it harder for libraries to depend on Guava (unless they
relocated <https://forgegradle.readthedocs.io/en/latest/user-guide/shading/>
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
<https://github.com/google/guava#important-warnings> 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
      <http://google.github.io/guava/releases/23.0/api/docs/com/google/common/base/CharMatcher.html#WHITESPACE>
      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
<https://groups.google.com/d/msgid/guava-announce/CAEvq2np26f2Hw0SW1KRkxyq4f3c3eYqLfWm0LHkiU2TkfPDvOA%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
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: <http://listman.redhat.com/archives/zanata-devel/attachments/20171003/92d06a85/attachment.htm>