The combination of 1 and 2 seems the more reasonable path to me. I'd propose to move to 18 in 2.1.0 adding the hacks to support 16 as @demobox suggested.
We can release 2.1.0 as soon as the compat code is in place, and also remove the hacks in the 2.2.0-SNAPSHOT immediately. This way we have the bridge release but we don't keep the hacks forever. Most users are probably in the 2.0.x releases, so dropping support for 16-17 in 2.2.0 looks reasonable. Also, I don't think we need to support 16, then 17; jumping from 16 to 18 leaving the "deprecation release" with the hacks should be enough to provide a smooth upgrade path. I. On Mar 31, 2017 7:19 AM, "Andrew Phillips" <aphill...@qrmedia.com> wrote: > How can we move forward here? >> > > Do we have any idea how much work would be needed to continue to support > users with Guava 16 and 17 if we moved to Guava 18 as the default? Assuming > that's even technically possible, of course. > > That would still leave us with hacks in the codebase, but those would > hopefully be temporary and could be phased out if and when it's deemed > acceptable to drop support for Guava 16 and then 17. > > Regards > > ap >
