I do not think we should double the work by putting in workarounds to 2.1.0 and updating the dependency for 2.2.0. Why not move directly to Guava 18 in 2.1.0?
On Fri, Mar 31, 2017 at 07:59:36AM +0200, Ignasi Barrera wrote: > 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" <[email protected]> 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 > > -- Andrew Gaul http://gaul.org/
