-1, I see little benefit to accelerating 2.0 or announcing dropping Java 6 support.
Why should we release 2.0 out of step with the agreed-upon major release cadence? If we cannot follow our own policy for the first release after agreeing upon a policy, what confidence does that give our users in subsequent releases, or in future policies? Users are not impressed by big, round version numbers and jclouds is unlikely to realize a big boost in interest due to 2.0. What benefit do you believe that announcing dropping Java 6 provides? We removed support to make development of jclouds easier and reduce our support matrix. We have only merged two small features which take advantage of Java 7; users will not see many differences when upgrading. Instead of creating an artificial marketing release, perhaps we could announce Amazon Glacier and soon Google Cloud Storage providers, which completes our support for all major object stores? Or announce the new Docker provider and improved SoftLayer support? Users have long requested some of these providers and delivering them is something tangible to crow about. Counter-proposal, we proceed with releases as we have since 1.6.0: 1.8.1 15-Sep-2014 1.8.2 01-Nov-2014 1.8.3 15-Dec-2014 2.0.0 01-Feb-2014 On Fri, Aug 29, 2014 at 12:51:15PM +0000, Everett Toews wrote: > Hi All, > > At our current release cadence we would reach 2.0.0 until Feb. 2015. I’d like > to propose that we release 2.0.0 in mid-Sept. for a number of reasons. > > 1. A big boost in interest for jclouds at JavaOne > > I’ll be giving an “Introduction to Apache jclouds” session at JavaOne on > Sept. 30. I think we could get a big boost in interest for jclouds if I > announce that we’ve gone to 2.0.0 and Java 7. Especially if we follow this up > with an ASF press release shortly before or after. > > 2. Using Java 7 > > Now that we’ve committed to using Java 7 it would be good to release it too. > It would also be nice if we release the Java 7 version of jclouds to our > users more than a month before the Java 7 EOL in Apr. 2015. ;) > > 3. Makes development a bit easier > > When back porting changes to 2.0.x branch we wouldn’t have to worry about > accidentally back porting something that is Java 7 specific like we do with > 1.8.x. > > > If people still need 1.8.1 then we can still release 1.8.1 alongside 2.0.0. > > It terms of dates we could do the following. > > Code freeze: Sept. 19 > Release begins: Sept. 22 > > Let me know what you think. > > Thanks, > Everett -- Andrew Gaul http://gaul.org/
