Upcoming changes to Guava releases

[Colin Decker]

Hi Guava community,

Starting with Guava 23.1 (which was released on Wednesday, September 27th), we're beginning to make some changes to how we handle Guava releases. The goal of these changes is to ensure that releases happen more frequently and predictably.

The biggest change is that we're moving to a schedule of releasing a new Guava version every two weeks rather than waiting for specific features (or some nebulously defined number of features) to get in before making a release. Under this new model, if a feature doesn't get in one release, well, there's another release in two weeks! On the other hand, if at release time, nothing has changed since the last release (or any changes are just really minor), we'll skip that release.

Note that this does not mean we'll be increasing the major version number every two weeks! When making a release, we'll be looking at the changes in that release and determining the version number in accordance with semantic versioning (this is what we've always been doing, but with more infrequent releases there has almost always been at least one breaking change, even if only to an @Beta API). We're also making some changes to our policies regarding backwards incompatible changes in general; there will be another post with details on that soon.

As part of this, there will be no more release candidates. They just don't make much sense when we're releasing every two weeks. If there's a problem with a release that would have been reported against a release candidate (which didn’t happen frequently), it can be corrected in the next release easily enough. And if there's an issue that needs to be corrected sooner than that, we can still do a quick patch release.

Finally (though really quite unrelated to the above), we're making a change to Guava version numbers. In 22.0, we started releasing an Android-focused Guava flavor as version 22.0-android alongside the JRE flavor with version 22.0. This caused some issues, particularly with systems that try to determine what the "newest" version of an artifact is. (Maven considered 22.0-android to be newer than 22.0, when in reality they're different flavors of the same version). See this issue and document for more on that. We're still going to differentiate between the Android and Java 8 flavors of Guava using the version number (because other solutions have problems that we consider even worse), but to make them more parallel, we're going to be suffixing the non-Android flavor with -jre. So the two flavors of Guava N will be N-jre and N-android. One will still be considered "newer" than the other, unfortunately, but the "newer" one will be N-jre. We do not plan to retroactively release -jre suffixed versions of any previous Guava releases.

All of these things are documented on our new Release Policy page. Let us know if you have any questions or feedback on these changes!

Thanks,

Colin Decker and the Guava team