Totally agree with Jeremy and Chris. I think it is reasonable to think that users that don't want to upgrade the JVM won't want to upgrade to the latest jclouds version (major changes, newest Guava and other deps, etc).
Keeping 1.7 compatible with 1.6 and dropping support for it in 1.8 sounds like a reasonable way to move forward. El 30/05/2014 00:46, "Chris Custine" <chris.cust...@gmail.com> escribió: > I agree with Jeremy, in that 1.8 seems like a reasonable point to start > requiring Java 7 as a minimum. I know many people are still using jclouds > 1.6.x and Java 6 so I don't think you will cause too much grief for anyone > moving up to the eventual jclouds 1.8 release (meaning, they are likely to > stay at jclouds 1.6 or 1.7 for quite some time anyway). > > Just my 2 cents. > > Chris > > -- > Chris Custine > > > > On Thu, May 29, 2014 at 9:32 AM, Jeremy Daggett < > jeremy.dagg...@rackspace.com> wrote: > >> I really appreciate that you brought this up Andrew! >> >> I have been through every Java version transition since v1.0. I know the >> challenges and pain points this decision might cause some developers. It >> will most likely be an issue in enterprise environments where Java >> runtimes can only change every couple of years. >> >> Technology changes. Java 6 is no longer supported. That alone should be >> the deciding factor for the project. >> >> >> In my experience, the industry best practice is to support the most >> current version and one previous. I actually really like what vert.x did >> in requiring a Java 7 (or newer) right from the start. >> >> Here is an idea for a potential transition plan: >> jclouds 1.7.x -> Java 6+ (maintenance branch to support Java 6+) >> jclouds 1.8.x -> Java 7+ >> >> >> In order to move jclouds forward, we need to drop support for Java 6. If >> it were totally up to me, I would vote to jump right to Java 8, but that >> is just my perspective. ;) >> >> /jd >> >> On 5/28/14, 11:57 AM, "Andrew Gaul" <g...@apache.org> wrote: >> >> >jclouds presently supports Java 6, 7, and 8 which imposes extra >> >development costs and prevents uptake of new language and library >> >features including try-with-resources, NIO.2, and HTTP client >> >improvements. Oracle ceased public updates to Java 6 in early 2013[1] >> >and jclouds could use this to guide its support strategy. The jclouds >> >developers would like to understand how many users continue to use Java >> >6 and what prevents upgrading to newer versions. Please respond to this >> >thread with any relevant information. Thanks! >> > >> >-- >> >Andrew Gaul >> >http://gaul.org/ >> >> >
