Thanks for breaking out some of our choices. I slightly prefer two major releases to address Guava pain immediately and require Java 7 later. Would 1.8.x branch from 1.7.x or from master? If we branch from master, we could delay the 2.0 release requiring Java 7 until later in the year.
On Mon, Jun 30, 2014 at 09:18:20PM +0000, Everett Toews wrote: > So we’ve reached consensus on moving to Java 7 in the next major release of > jclouds [1]. > > Jumping to 2.0 as our next release (due mid-July) is way too abrupt a change > for our users. We need to give them some time to adapt and plan for it. 2 > weeks is too short an amount of time for our users to digest this change, 2 > months would be reasonable. > > Supposedly our next release should be 1.7.4 but, as Gaul pointed out in the > other thread [1], many users are feeling the pain of us not upgrading Guava, > which we only do in minor releases (e.g. the next Guava upgrade should happen > in 1.8). > > So how about this? > > jclouds 1.8 (due mid-July) is our next version and the last version of > jclouds to work with Java 6. We can also bump the Guava dep at this time. > > OR > > jclouds 1.7.4 (due mid-July) is our next version and the last version of > jclouds to work with Java 6. We can also bump the Guava dep at this time. > > AND > > jclouds 2.0 (due early Sept.) is the first version of jclouds to work with > Java 7. > > As of jclouds 2.0 we adopt the major release cadence (which we’re converging > on). > > WDYT? > > Everett > > [1] http://jclouds.markmail.org/message/p2mmfvtnto3srpmq -- Andrew Gaul http://gaul.org/
