I will move the things already done into the 1.8.1 section, so what I'm saying is more clear. I understand that probably few were able to follow all the backlogged work completed in the last 7 days.
On Fri, Oct 10, 2014 at 8:25 AM, Adrian Cole <adrian.f.c...@gmail.com> wrote: > 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
