I’m comfortable with a roadmap like this. Primarily to stop the bleeding on backporting pain.
For example, back when we were considering the switch to Java 7 (more on that in a later email) in 2.0.0 I was thinking we could release 1.8.0 and 2.0.0 alongside each other, in part to solve the backporting issue. Unfortunately I didn’t articulate that very well. Because otherwise you wind up delaying all of your Java 7 changes until just before the 2.0.0 release like [1]. Then you get an avalanche of changes. It doesn’t make a lot of sense to me. When it comes to release cadence, we need to find a balance between the developer experience for our users and the developer experience for our contributors. Making major releases too often with backwards incompatible changes is hard on our users but makes life easier for our contributors (no backporting, less code to maintain, etc.). I’d like to try solving for both by trying out JDiff [2] as Guava does. I’ll start by diffing between the 1.8.0 and 1.8.1 releases and including that in our next release notes. If we get better at communicating API changes, perhaps users will be okay with an occasional major release out-of-cadence. I’m also very much looking forward to "Refactor project structure to streamline releases”. :) Everett [1] https://github.com/jclouds/jclouds/pull/506 [2] http://javadiff.cvs.sourceforge.net/viewvc/javadiff/jdiff/doc/jdiff.html On Oct 10, 2014, at 10:59 AM, Adrian Cole <adrian.f.c...@gmail.com> wrote: > 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
