PS concrete proposal on this topic is.. s/2.0.0/1.9.0 as it is really not worth the major version bump, but do release it, even if it means s/MoreObjects/Objects. This will release the fixes that didn't make it to 1.8.x.
don't fork dev until there's a good reason to. do find those reasons. feel free to tell me thanks, but no thanks.. we like our roadmap. -A On Thu, Oct 9, 2014 at 4:06 PM, Adrian Cole <adrian.f.c...@gmail.com> 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
