" I do not understand the motivations to promote providers out of labs in minor releases, but doing so provides no functional benefit to users."
Promotion out of labs establishes that this provider is no longer going to thrash, be in an inconsistent bug fix state, and has some notion of being more supported than it was. It is hard to take this and at the same time say there's no benefit to users. That said, I haven't talked to the users that you have. Maybe you can share their feedback so that we can more sensibly delay provider promotion until next year? On Fri, Oct 10, 2014 at 10:40 AM, Andrew Gaul <g...@apache.org> wrote: > 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/
