You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Adrian Cole <ad...@gmail.com> on 2014/10/10 01:06:37 UTC
Roadmap opinion
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
Re: Roadmap opinion
Posted by Everett Toews <ev...@RACKSPACE.COM>.
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 <ad...@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 <ad...@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 <ad...@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" <ev...@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 <ad...@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 <ad...@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
Re: Roadmap opinion
Posted by Adrian Cole <ad...@gmail.com>.
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 <ad...@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 <ad...@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" <ev...@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 <ad...@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 <ad...@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
Re: Roadmap opinion
Posted by Adrian Cole <ad...@gmail.com>.
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 <ad...@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" <ev...@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 <ad...@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 <ad...@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
Re: Roadmap opinion
Posted by Adrian Cole <ad...@gmail.com>.
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" <ev...@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 <ad...@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 <ad...@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
>
Re: Roadmap opinion
Posted by Everett Toews <ev...@RACKSPACE.COM>.
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 <ad...@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 <ad...@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
Re: Roadmap opinion
Posted by Adrian Cole <ad...@gmail.com>.
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 <ad...@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
Re: Roadmap opinion
Posted by Adrian Cole <ad...@gmail.com>.
Note I would also highly recommend a global revert of MoreObjects back
to Objects, again until we have a significant reason to deal with that
maintenance burden.
Objects.toStringHelper is not scheduled to be removed until June 2016,
and MoreObjects.X causes a mess for folks not following guava updates
as fast as we do. I am *this* close to suggesting not using
Objects.toStringHelper regardless of things like auto-value as it is
disastrous for portability. We should favor compatibility way over
staying 2 years ahead of guava deprecation policy.
WRT android. Let's set the language level back to 1.6 and plop this
into the parent pom in a way that projects inherit it. Animal sniffer
also checks api usage. If that turns into pandora's box, we can table
animal sniffer until we can fix around it.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>animal-sniffer-maven-plugin</artifactId>
<version>1.11</version>
<executions>
<execution>
<phase>test</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
<configuration>
<signature>
<groupId>org.codehaus.mojo.signature</groupId>
<artifactId>java16</artifactId>
<version>1.1</version>
</signature>
</configuration>
</plugin>
On Fri, Oct 17, 2014 at 2:45 PM, Chris Custine <ch...@gmail.com> wrote:
>
> I was waiting until after 1.8.1 was released, but since you ask... I think this or something like it sounds like a good idea, however I don’t think we need to revert very much if anything. My understanding from reading about this issue over the weekend was that there are only very specific parts of Java 7 usage that would prevent it from working on anything older than 4.4. Specifically, try-with-resources seems the only real issue. From what I read (and it is fairly well documented) that is the only part that is of concern. If we adopt this route temporarily and try to evaluate what it would take to have a usable jclouds on Android, we could simply have a wiki doc with the guidelines I have seen on what language level features of Java 7 are suitable for the best level of Android compatibility.
>
> I was also going to suggest a 1.9 release to include oauth and gce graduating out of labs, and any other bits that we decided to leave out of 1.8.1 but which we might not want to wait months for 2.0. Just a thought.
>
> Chris
> --
> Chris Custine
>
>
>
> On October 17, 2014 at 8:41:02 AM, Andrew Phillips (aphillips@qrmedia.com(mailto:aphillips@qrmedia.com)) wrote:
>
>> > I can’t argue with that. If we keep this opportunity open and
>> > encourage the exploration, and still nobody steps up for it then I
>> > think it is fair to reevaluate this again.
>>
>> Just in terms of concrete implications: would we want to consider a
>> 1.9.x that still supports Java 6, reverting the Java 7-only on master
>> for that? Or how else would you suggest going about this?
>>
>> ap
>
Re: Roadmap opinion
Posted by Chris Custine <ch...@gmail.com>.
I was waiting until after 1.8.1 was released, but since you ask... I think this or something like it sounds like a good idea, however I don’t think we need to revert very much if anything. My understanding from reading about this issue over the weekend was that there are only very specific parts of Java 7 usage that would prevent it from working on anything older than 4.4. Specifically, try-with-resources seems the only real issue. From what I read (and it is fairly well documented) that is the only part that is of concern. If we adopt this route temporarily and try to evaluate what it would take to have a usable jclouds on Android, we could simply have a wiki doc with the guidelines I have seen on what language level features of Java 7 are suitable for the best level of Android compatibility.
I was also going to suggest a 1.9 release to include oauth and gce graduating out of labs, and any other bits that we decided to leave out of 1.8.1 but which we might not want to wait months for 2.0. Just a thought.
Chris
--
Chris Custine
On October 17, 2014 at 8:41:02 AM, Andrew Phillips (aphillips@qrmedia.com(mailto:aphillips@qrmedia.com)) wrote:
> > I can’t argue with that. If we keep this opportunity open and
> > encourage the exploration, and still nobody steps up for it then I
> > think it is fair to reevaluate this again.
>
> Just in terms of concrete implications: would we want to consider a
> 1.9.x that still supports Java 6, reverting the Java 7-only on master
> for that? Or how else would you suggest going about this?
>
> ap
Re: Roadmap opinion
Posted by Andrew Phillips <ap...@qrmedia.com>.
> I can’t argue with that. If we keep this opportunity open and
> encourage the exploration, and still nobody steps up for it then I
> think it is fair to reevaluate this again.
Just in terms of concrete implications: would we want to consider a
1.9.x that still supports Java 6, reverting the Java 7-only on master
for that? Or how else would you suggest going about this?
ap
Re: Roadmap opinion
Posted by Chris Custine <ch...@gmail.com>.
That said, I would like to see us keep the door open for Android dev too. It keeps coming up and people keep trying to use jclouds on Android so I think it’s worthwhile to try it, if someone is willing to run with it. But if nothing significant happens with it in 6 months or so, I think we would want to reconsider that and just forge ahead with a newer version of Java.
I can’t argue with that. If we keep this opportunity open and encourage the exploration, and still nobody steps up for it then I think it is fair to reevaluate this again.
Chris
--
Chris Custine
On October 16, 2014 at 4:13:21 PM, Everett Toews (everett.toews@rackspace.com) wrote:
On Oct 12, 2014, at 6:30 PM, Chris Custine <ch...@gmail.com> wrote:
> * On promoting labs providers in minor releases: One of my main concerns about labs providers is that they frequently get ignored when doing refactoring in the upstream jclouds repo and are left broken for periods of time until someone has time to bring them in sync with upstream jclouds. The chances of this happening are probably much higher while working on a major release like 2.0, so I feel that if the provider is ready to promote, why delay until a major release when you can bring it in sooner and give it more visibility for the inevitable refactorings of a major release?
+1 to promoting providers whenever they’re ready regardless of major/minor release to avoid refactoring pain.
> * Java 7 vs Java 6 API level: I had not considered the implications moving to Java 7 API level would have on any potential Android development. I don’t do any Android development but I understand the try-with-resources issue and I think it is fair to reconsider and revise some of the earlier decisions in order to keep this door open. I don’t think this is a major issue, we can still use most Java 7 language features with specific exceptions such as try-with-resources, and these issues are fairly clearly documented and well known from the brief googling that I did.
I hadn’t considered the Android aspect either. I dipped my toe into Android development a while back (I even attended AnDevCon) and learned that serious Android developers are very cognizant of the performance and memory footprint of the dependencies they bring into their apps. Both of those things would need to be addressed with jclouds on Android.
That said, I would like to see us keep the door open for Android dev too. It keeps coming up and people keep trying to use jclouds on Android so I think it’s worthwhile to try it, if someone is willing to run with it. But if nothing significant happens with it in 6 months or so, I think we would want to reconsider that and just forge ahead with a newer version of Java.
Everett
Re: Roadmap opinion
Posted by Everett Toews <ev...@RACKSPACE.COM>.
On Oct 12, 2014, at 6:30 PM, Chris Custine <ch...@gmail.com> wrote:
> * On promoting labs providers in minor releases: One of my main concerns about labs providers is that they frequently get ignored when doing refactoring in the upstream jclouds repo and are left broken for periods of time until someone has time to bring them in sync with upstream jclouds. The chances of this happening are probably much higher while working on a major release like 2.0, so I feel that if the provider is ready to promote, why delay until a major release when you can bring it in sooner and give it more visibility for the inevitable refactorings of a major release?
+1 to promoting providers whenever they’re ready regardless of major/minor release to avoid refactoring pain.
> * Java 7 vs Java 6 API level: I had not considered the implications moving to Java 7 API level would have on any potential Android development. I don’t do any Android development but I understand the try-with-resources issue and I think it is fair to reconsider and revise some of the earlier decisions in order to keep this door open. I don’t think this is a major issue, we can still use most Java 7 language features with specific exceptions such as try-with-resources, and these issues are fairly clearly documented and well known from the brief googling that I did.
I hadn’t considered the Android aspect either. I dipped my toe into Android development a while back (I even attended AnDevCon) and learned that serious Android developers are very cognizant of the performance and memory footprint of the dependencies they bring into their apps. Both of those things would need to be addressed with jclouds on Android.
That said, I would like to see us keep the door open for Android dev too. It keeps coming up and people keep trying to use jclouds on Android so I think it’s worthwhile to try it, if someone is willing to run with it. But if nothing significant happens with it in 6 months or so, I think we would want to reconsider that and just forge ahead with a newer version of Java.
Everett
Re: Roadmap opinion
Posted by Chris Custine <ch...@gmail.com>.
I didn’t have much spare time to comment on this thread last week but I wanted to follow up with a couple of thoughts.
* On promoting labs providers in minor releases: One of my main concerns about labs providers is that they frequently get ignored when doing refactoring in the upstream jclouds repo and are left broken for periods of time until someone has time to bring them in sync with upstream jclouds. The chances of this happening are probably much higher while working on a major release like 2.0, so I feel that if the provider is ready to promote, why delay until a major release when you can bring it in sooner and give it more visibility for the inevitable refactorings of a major release?
* Java 7 vs Java 6 API level: I had not considered the implications moving to Java 7 API level would have on any potential Android development. I don’t do any Android development but I understand the try-with-resources issue and I think it is fair to reconsider and revise some of the earlier decisions in order to keep this door open. I don’t think this is a major issue, we can still use most Java 7 language features with specific exceptions such as try-with-resources, and these issues are fairly clearly documented and well known from the brief googling that I did.
* Release cadence, version numbering, etc.: I know my opinion on this is unpopular, but as I said in previous discussions on this, I think predictable release schedules on an open source project with community diversity is only going to introduce pain in the form of unpredictable code quality and rushed features. Predictable releases only really work when everyone is aligned on the same intersection of priorities, availability, and interest. Frankly, that only happens consistently on projects where many people work for the same company. I am much more in favor of roadmap driven releases where everyone can keep their eye on a common set of overall goals, which is more to do with adding value to the release than shipping it within a designated timeframe. I simply do not understand the need for consistent and scheduled releases of an open source project, other than bug fix only releases.
And finally, I think the main thing is to be flexible and willing to evolve constantly. The growing pains and lively discussions are the byproduct of successful diversification of this project and the growth of the community. These are all positive aspects of the evolution of the project.
-CC
--
Chris Custine
On October 10, 2014 at 1:06:35 PM, Adrian Cole (adrian.f.cole@gmail.com) wrote:
" I do not understand the motivations to promote providers out
of labs in minor releases, but doing so provides no functional benefit
to users."
Promotion out of labs establishes that this provider is no longer
going to thrash, be in an inconsistent bug fix state, and has some
notion of being more supported than it was. It is hard to take this
and at the same time say there's no benefit to users. That said, I
haven't talked to the users that you have. Maybe you can share their
feedback so that we can more sensibly delay provider promotion until
next year?
On Fri, Oct 10, 2014 at 10:40 AM, Andrew Gaul <ga...@apache.org> wrote:
> We discussed several cadences for major releases and decided on six
> months as a reasonable time frame. The primary motivations were to give
> release predictability and eliminate some of the painful feature
> backports. I do not understand the motivations to promote providers out
> of labs in minor releases, but doing so provides no functional benefit
> to users. Running additional 1.8 releases after 2.0 is an option we
> left open but have not committed to to accommodate potential but not
> identified Java 6 users. As for Java 7, please refer to the original
> thread:
>
> https://www.mail-archive.com/user@jclouds.apache.org/msg00708.html
>
> Notably, no users objected to this new requirement, several developers
> expressed enthusiasm for this change, and it reduces compatibility
> matrix, especially for the HTTP client. Also no user has reported a
> JIRA issue with Java 6 since moving to ASF. We have already merged
> several enhancements enabled by Java 7[1][2] and this requirement was
> not motivated by minor code improvements like try-with-resources. I
> strongly believe we should continue on the path which we already
> discussed and agreed to.
>
> [1] https://issues.apache.org/jira/browse/JCLOUDS-264
> [2] https://issues.apache.org/jira/browse/JCLOUDS-658
>
> On Thu, Oct 09, 2014 at 04:06:37PM -0700, Adrian Cole 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
>
> --
> Andrew Gaul
> http://gaul.org/
Re: Roadmap opinion
Posted by Adrian Cole <ad...@gmail.com>.
" I do not understand the motivations to promote providers out
of labs in minor releases, but doing so provides no functional benefit
to users."
Promotion out of labs establishes that this provider is no longer
going to thrash, be in an inconsistent bug fix state, and has some
notion of being more supported than it was. It is hard to take this
and at the same time say there's no benefit to users. That said, I
haven't talked to the users that you have. Maybe you can share their
feedback so that we can more sensibly delay provider promotion until
next year?
On Fri, Oct 10, 2014 at 10:40 AM, Andrew Gaul <ga...@apache.org> wrote:
> We discussed several cadences for major releases and decided on six
> months as a reasonable time frame. The primary motivations were to give
> release predictability and eliminate some of the painful feature
> backports. I do not understand the motivations to promote providers out
> of labs in minor releases, but doing so provides no functional benefit
> to users. Running additional 1.8 releases after 2.0 is an option we
> left open but have not committed to to accommodate potential but not
> identified Java 6 users. As for Java 7, please refer to the original
> thread:
>
> https://www.mail-archive.com/user@jclouds.apache.org/msg00708.html
>
> Notably, no users objected to this new requirement, several developers
> expressed enthusiasm for this change, and it reduces compatibility
> matrix, especially for the HTTP client. Also no user has reported a
> JIRA issue with Java 6 since moving to ASF. We have already merged
> several enhancements enabled by Java 7[1][2] and this requirement was
> not motivated by minor code improvements like try-with-resources. I
> strongly believe we should continue on the path which we already
> discussed and agreed to.
>
> [1] https://issues.apache.org/jira/browse/JCLOUDS-264
> [2] https://issues.apache.org/jira/browse/JCLOUDS-658
>
> On Thu, Oct 09, 2014 at 04:06:37PM -0700, Adrian Cole 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
>
> --
> Andrew Gaul
> http://gaul.org/
Re: Roadmap opinion
Posted by Adrian Cole <ad...@gmail.com>.
If others agree with you, go for it.
One thing I'll leave you with is this question. How much traffic does
user list get since moving to ASF? Are you confident that this
represents the jclouds user base? If not, I would look at asking users
more directly as I only see a single user responding, who actually
expressed a mild concern.
I believe jclouds would be in a better place if it were more concerned
with finding its users then making up arbitrary goals and trying to
meet them.
-A
On Fri, Oct 10, 2014 at 10:40 AM, Andrew Gaul <ga...@apache.org> wrote:
> We discussed several cadences for major releases and decided on six
> months as a reasonable time frame. The primary motivations were to give
> release predictability and eliminate some of the painful feature
> backports. I do not understand the motivations to promote providers out
> of labs in minor releases, but doing so provides no functional benefit
> to users. Running additional 1.8 releases after 2.0 is an option we
> left open but have not committed to to accommodate potential but not
> identified Java 6 users. As for Java 7, please refer to the original
> thread:
>
> https://www.mail-archive.com/user@jclouds.apache.org/msg00708.html
>
> Notably, no users objected to this new requirement, several developers
> expressed enthusiasm for this change, and it reduces compatibility
> matrix, especially for the HTTP client. Also no user has reported a
> JIRA issue with Java 6 since moving to ASF. We have already merged
> several enhancements enabled by Java 7[1][2] and this requirement was
> not motivated by minor code improvements like try-with-resources. I
> strongly believe we should continue on the path which we already
> discussed and agreed to.
>
> [1] https://issues.apache.org/jira/browse/JCLOUDS-264
> [2] https://issues.apache.org/jira/browse/JCLOUDS-658
>
> On Thu, Oct 09, 2014 at 04:06:37PM -0700, Adrian Cole 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
>
> --
> Andrew Gaul
> http://gaul.org/
Re: Roadmap opinion
Posted by Andrew Gaul <ga...@apache.org>.
We discussed several cadences for major releases and decided on six
months as a reasonable time frame. The primary motivations were to give
release predictability and eliminate some of the painful feature
backports. I do not understand the motivations to promote providers out
of labs in minor releases, but doing so provides no functional benefit
to users. Running additional 1.8 releases after 2.0 is an option we
left open but have not committed to to accommodate potential but not
identified Java 6 users. As for Java 7, please refer to the original
thread:
https://www.mail-archive.com/user@jclouds.apache.org/msg00708.html
Notably, no users objected to this new requirement, several developers
expressed enthusiasm for this change, and it reduces compatibility
matrix, especially for the HTTP client. Also no user has reported a
JIRA issue with Java 6 since moving to ASF. We have already merged
several enhancements enabled by Java 7[1][2] and this requirement was
not motivated by minor code improvements like try-with-resources. I
strongly believe we should continue on the path which we already
discussed and agreed to.
[1] https://issues.apache.org/jira/browse/JCLOUDS-264
[2] https://issues.apache.org/jira/browse/JCLOUDS-658
On Thu, Oct 09, 2014 at 04:06:37PM -0700, Adrian Cole 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
--
Andrew Gaul
http://gaul.org/