I didn’t have much spare time to comment on this thread last week but I wanted to follow up with a couple of thoughts.
* On promoting labs providers in minor releases: One of my main concerns about labs providers is that they frequently get ignored when doing refactoring in the upstream jclouds repo and are left broken for periods of time until someone has time to bring them in sync with upstream jclouds. The chances of this happening are probably much higher while working on a major release like 2.0, so I feel that if the provider is ready to promote, why delay until a major release when you can bring it in sooner and give it more visibility for the inevitable refactorings of a major release? * Java 7 vs Java 6 API level: I had not considered the implications moving to Java 7 API level would have on any potential Android development. I don’t do any Android development but I understand the try-with-resources issue and I think it is fair to reconsider and revise some of the earlier decisions in order to keep this door open. I don’t think this is a major issue, we can still use most Java 7 language features with specific exceptions such as try-with-resources, and these issues are fairly clearly documented and well known from the brief googling that I did. * Release cadence, version numbering, etc.: I know my opinion on this is unpopular, but as I said in previous discussions on this, I think predictable release schedules on an open source project with community diversity is only going to introduce pain in the form of unpredictable code quality and rushed features. Predictable releases only really work when everyone is aligned on the same intersection of priorities, availability, and interest. Frankly, that only happens consistently on projects where many people work for the same company. I am much more in favor of roadmap driven releases where everyone can keep their eye on a common set of overall goals, which is more to do with adding value to the release than shipping it within a designated timeframe. I simply do not understand the need for consistent and scheduled releases of an open source project, other than bug fix only releases. And finally, I think the main thing is to be flexible and willing to evolve constantly. The growing pains and lively discussions are the byproduct of successful diversification of this project and the growth of the community. These are all positive aspects of the evolution of the project. -CC -- Chris Custine On October 10, 2014 at 1:06:35 PM, Adrian Cole (adrian.f.c...@gmail.com) wrote: " 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/
