Can't login (keeps timing out) Here are the changes. Hopefully, it is more obvious what I meant, now.
---- 1.8.0 Target date: Aug 2014 Themes: De-async compute providers Add Docker provider, JCLOUDS-500 Add Glacier provider, JCLOUDS-458 1.8.1 Code Freeze: Oct. 10, 2014 EOD Release: Oct. 17, 2014 Themes: deprecatchup Promote jclouds-chef to core Promote openstack-swift Promote rackspace-cloudfiles-* Remove the CloudSigma v1 provider as it's been retired (depends on the previous one) JCLOUDS-692 Remove deprecated interfaces and methods (Async apis, AsyncBlobStore, Util methods for executorService) plenty more... 1.8.2 Code Freeze: Nov. 17, 2014 EOD Release: Nov. 21, 2014 Themes: out of the labs into the fire Promote azurecompute Promote Google Cloud Storage JCLOUDS-458 Promote Google Compute Engine Promote DigitalOcean provider to the v2 API JCLOUDS-613 Promote CloudSigma v2 provider JCLOUDS-292 plenty more... 1.9.0 Code Freeze: Nov. 17, 2014 EOD Release: Nov. 21, 2014 Themes: sync with drift Allows us to release the fixes that are currently in master without awaiting next year or forcing a minimum JRE 1.9.1 Code Freeze: Jan. 5, 2015 EOD Release: Jan. 9, 2015 Themes: Minor Release 2.0.0 Code Freeze: Feb. 16, 2015 EOD Release: Feb. 20, 2015 Themes: Require users to have a minimum JRE 7, JCLOUDS-652 (adrian thinks this is not high-value or even a useful goal) Refactor project structure to streamline releases Future Themes: Reduce API calls through additional, configurable caching Reduce reflection overhead On Fri, Oct 10, 2014 at 8:35 AM, Adrian Cole <adrian.f.c...@gmail.com> wrote: > 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
