Everett, Assuming you have read the roadmap yourself, you would notive there are very few line-by-lines to discuss. It basically says do some refactoring or minor work, add a couple providers by sometime in 2015 and call that version 2. Most of that work is done and a good bit of the rest is simply adding providers or requiring users to use JRE 7+. It is quite uninspired.
In doing backports, I have noticed that the main difference (at least in providers) between 1.8.x and 2.x are Guava classes MoreObjects vs Objects used to make hashCode and equals. That and bugfix and spacing disparities. By s/MoreObjects/Objects, I am referring to the only sed command needed to make at least some of that code compatible with whatever version of guava concerns we had. That might make the code that has been cooking in 2.x shippable as opposed to awaiting next year as the roadmap suggests. On Oct 10, 2014 6:18 AM, "Everett Toews" <everett.to...@rackspace.com> wrote: > Hey Adrian, > > Since your return there has been a lot of change (and that’s not a bad > thing). I was at JavaOne when the pull request avalanche started and, > frankly, I haven’t really caught up with everything that’s changed. The > gist I’m getting from the PRs is paying down tech debt. So far, I’ve been > going with the flow for the sake of progress. > > For this however, I need to push back. We settled on the current roadmap > after some long discussions. I need more than "s/2.0.0/1.9.0/" and > "s/MoreObjects/Objects/" as a concrete proposal. The purpose of the roadmap > is to provide our users with some predicability. > > Can you please take the entire text of the current Roadmap and paste it > into this thread and make the modifications you have in mind? > > This will give everyone a clear idea of what you want to achieve. We can > ignore dates for the moment as our release schedule has already been > derailed. > > Thanks, > Everett > > P.S. I'm off today and the entire weekend. I'll pick this thread back up > on Monday. > > > From: Adrian Cole <adrian.f.c...@gmail.com> > Sent: Oct 9, 2014 6:19 PM > To: dev@jclouds.apache.org > Subject: Re: Roadmap opinion > > 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 >
