We discussed several cadences for major releases and decided on six months as a reasonable time frame. The primary motivations were to give release predictability and eliminate some of the painful feature backports. I do not understand the motivations to promote providers out of labs in minor releases, but doing so provides no functional benefit to users. Running additional 1.8 releases after 2.0 is an option we left open but have not committed to to accommodate potential but not identified Java 6 users. As for Java 7, please refer to the original thread:
https://www.mail-archive.com/user@jclouds.apache.org/msg00708.html Notably, no users objected to this new requirement, several developers expressed enthusiasm for this change, and it reduces compatibility matrix, especially for the HTTP client. Also no user has reported a JIRA issue with Java 6 since moving to ASF. We have already merged several enhancements enabled by Java 7[1][2] and this requirement was not motivated by minor code improvements like try-with-resources. I strongly believe we should continue on the path which we already discussed and agreed to. [1] https://issues.apache.org/jira/browse/JCLOUDS-264 [2] https://issues.apache.org/jira/browse/JCLOUDS-658 On Thu, Oct 09, 2014 at 04:06:37PM -0700, Adrian Cole wrote: > Hi, team. > > I was awol during the discussion of this, but I figured it would be at > least anecdotally interesting to hear my 2p on it. > > https://wiki.apache.org/jclouds/Roadmap > > Firstly, a long-lived 1.8 branch seems a bad idea. This release has > basically been merge hell because folks don't always pull in fixes or > changes. > > Moreover Java 7 is not really a feature anyone cares about. Not in > 2014 anyway. I mean no-one is knocking down our doors and saying.. if > only you used try-with-resources internally.. my project would need 2k > less lines of code! > > Java 8, if it was exposed in a way that helped users, maybe. A better > interface for compute, that more neatly aligns with containers, or > some other user-feature.. Sure. That would make it worthwhile for a > longer lived branch. > > What I'm trying to say is lets please step back, recognize how very > much work even one release is, and think about if this idea makes any > sense. I suspect after reflection, and hopefully asking our users, we > could come up with something compelling enough to justify a dual-dev > path. > > Final thoughts are that the roadmap looks excruciatingly long for such > small work. If it is that hard to do work, we have other fish to fry. > > Yeah, fly-by review by someone who was awol, but hopefully doing a > crap-ton of overdue maintenance buys me the cred to at least comment > here. > -A -- Andrew Gaul http://gaul.org/
