Impact of racing towards the next guava

[Adrian Cole <ad...@gmail.com>]

Hi, team.

I feel the need to reiterate something, which may not impact everyone, but
should be taken into consideration nevertheless.

jclouds is best a part of a platform. As a library, it needs to take care
not to make that impossible. Unlike some of our dayjobs, we cannot treat
jclouds as a monorepo or a monoculture, where we can assert a particular
version makes sense for us, then switch immediately to it.

The idea of being runtime portable is a part of our legacy and played a
part in the large adoption jclouds had prior to entering the ASF.

We've drifted from there. We moved to guava 17 in jclouds 1.8 without
analyzing the impact on our ecosystem. Core tools like jenkins weren't
consulted and may not work at all now. I'm willing to bet that many of the apps
that use jclouds <https://jclouds.apache.org/community/users/> either can't
work or were forced into a guava upgrade solely because we made them.

Other platforms and potential integrations are even more difficult now.
For example, jclouds 1.8 is now incompatible with platforms from the last 3
companies I've worked at: Netflix, Square, and Twitter. While the ceiling
version is 16.0.1 across the three, there are some in the 14 range, and a
couple projects at 11!

I asking, if not begging, to please not forget the legacy which in part led
us to where we are today. Please consider greatly the impact of runtime
portability.

If guava makes jclouds impossible, jclouds is impossible. Please don't
force guava versions without thinking it through and asking diverse users,
or at least doing an industry poll on what is sustainable. It is really
burdensome to backport or revert this stuff, and we all have more important
work to do.

In summary, we want to be known for making cloud easy, not making
dependency conflicts the norm.

-A

Re: Impact of racing towards the next guava

[Ignasi Barrera <na...@apache.org>]

+1. jclouds is a library that should fit wherever it is deployed. We can't
assume it will be the main building block in the platform where it lives ,
and we have to make sure we are as most compatible as possible.
El 24/10/2014 23:19, "Andrew Bayer" <an...@gmail.com> escribió:

> So many +1s. I really don't think that we *need* to be upgrading Guava
> all the time. To upgrade core dependency libraries like Guava, we need
> to have a discussion about what the benefits would be, who would be
> hurt if we upgraded, etc.
>
> A.
>
> On Fri, Oct 24, 2014 at 1:38 PM, Inbar Stolberg <in...@gmail.com>
> wrote:
> > +1
> > We almost didn't make the upgrade to 1.8
> > We changed to 1.8 code and used Andrew.G patch to downgrade guava to 16
> ...
> >
> > On Friday, October 24, 2014, Matt Stephenson <ma...@apache.org>
> wrote:
> >
> >> +1
> >>
> >> We shaded in guava for the appengine SDK, to try to get around this,
> which
> >> lead to other problems...
> >>
> >> Matt
> >> On Oct 24, 2014 12:49 PM, "Adrian Cole" <adrian.f.cole@gmail.com
> >> <javascript:;>> wrote:
> >>
> >> > Hi, team.
> >> >
> >> > I feel the need to reiterate something, which may not impact everyone,
> >> but
> >> > should be taken into consideration nevertheless.
> >> >
> >> > jclouds is best a part of a platform. As a library, it needs to take
> care
> >> > not to make that impossible. Unlike some of our dayjobs, we cannot
> treat
> >> > jclouds as a monorepo or a monoculture, where we can assert a
> particular
> >> > version makes sense for us, then switch immediately to it.
> >> >
> >> > The idea of being runtime portable is a part of our legacy and played
> a
> >> > part in the large adoption jclouds had prior to entering the ASF.
> >> >
> >> > We've drifted from there. We moved to guava 17 in jclouds 1.8 without
> >> > analyzing the impact on our ecosystem. Core tools like jenkins weren't
> >> > consulted and may not work at all now. I'm willing to bet that many of
> >> the
> >> > apps
> >> > that use jclouds <https://jclouds.apache.org/community/users/> either
> >> > can't
> >> > work or were forced into a guava upgrade solely because we made them.
> >> >
> >> > Other platforms and potential integrations are even more difficult
> now.
> >> > For example, jclouds 1.8 is now incompatible with platforms from the
> >> last 3
> >> > companies I've worked at: Netflix, Square, and Twitter. While the
> ceiling
> >> > version is 16.0.1 across the three, there are some in the 14 range,
> and a
> >> > couple projects at 11!
> >> >
> >> > I asking, if not begging, to please not forget the legacy which in
> part
> >> led
> >> > us to where we are today. Please consider greatly the impact of
> runtime
> >> > portability.
> >> >
> >> > If guava makes jclouds impossible, jclouds is impossible. Please don't
> >> > force guava versions without thinking it through and asking diverse
> >> users,
> >> > or at least doing an industry poll on what is sustainable. It is
> really
> >> > burdensome to backport or revert this stuff, and we all have more
> >> important
> >> > work to do.
> >> >
> >> > In summary, we want to be known for making cloud easy, not making
> >> > dependency conflicts the norm.
> >> >
> >> > -A
> >> >
> >>
>

Re: Impact of racing towards the next guava

[Andrew Bayer <an...@gmail.com>]

So many +1s. I really don't think that we *need* to be upgrading Guava
all the time. To upgrade core dependency libraries like Guava, we need
to have a discussion about what the benefits would be, who would be
hurt if we upgraded, etc.

A.

On Fri, Oct 24, 2014 at 1:38 PM, Inbar Stolberg <in...@gmail.com> wrote:
> +1
> We almost didn't make the upgrade to 1.8
> We changed to 1.8 code and used Andrew.G patch to downgrade guava to 16 ...
>
> On Friday, October 24, 2014, Matt Stephenson <ma...@apache.org> wrote:
>
>> +1
>>
>> We shaded in guava for the appengine SDK, to try to get around this, which
>> lead to other problems...
>>
>> Matt
>> On Oct 24, 2014 12:49 PM, "Adrian Cole" <adrian.f.cole@gmail.com
>> <javascript:;>> wrote:
>>
>> > Hi, team.
>> >
>> > I feel the need to reiterate something, which may not impact everyone,
>> but
>> > should be taken into consideration nevertheless.
>> >
>> > jclouds is best a part of a platform. As a library, it needs to take care
>> > not to make that impossible. Unlike some of our dayjobs, we cannot treat
>> > jclouds as a monorepo or a monoculture, where we can assert a particular
>> > version makes sense for us, then switch immediately to it.
>> >
>> > The idea of being runtime portable is a part of our legacy and played a
>> > part in the large adoption jclouds had prior to entering the ASF.
>> >
>> > We've drifted from there. We moved to guava 17 in jclouds 1.8 without
>> > analyzing the impact on our ecosystem. Core tools like jenkins weren't
>> > consulted and may not work at all now. I'm willing to bet that many of
>> the
>> > apps
>> > that use jclouds <https://jclouds.apache.org/community/users/> either
>> > can't
>> > work or were forced into a guava upgrade solely because we made them.
>> >
>> > Other platforms and potential integrations are even more difficult now.
>> > For example, jclouds 1.8 is now incompatible with platforms from the
>> last 3
>> > companies I've worked at: Netflix, Square, and Twitter. While the ceiling
>> > version is 16.0.1 across the three, there are some in the 14 range, and a
>> > couple projects at 11!
>> >
>> > I asking, if not begging, to please not forget the legacy which in part
>> led
>> > us to where we are today. Please consider greatly the impact of runtime
>> > portability.
>> >
>> > If guava makes jclouds impossible, jclouds is impossible. Please don't
>> > force guava versions without thinking it through and asking diverse
>> users,
>> > or at least doing an industry poll on what is sustainable. It is really
>> > burdensome to backport or revert this stuff, and we all have more
>> important
>> > work to do.
>> >
>> > In summary, we want to be known for making cloud easy, not making
>> > dependency conflicts the norm.
>> >
>> > -A
>> >
>>

Re: Impact of racing towards the next guava

[Inbar Stolberg <in...@gmail.com>]

+1
We almost didn't make the upgrade to 1.8
We changed to 1.8 code and used Andrew.G patch to downgrade guava to 16 ...

On Friday, October 24, 2014, Matt Stephenson <ma...@apache.org> wrote:

> +1
>
> We shaded in guava for the appengine SDK, to try to get around this, which
> lead to other problems...
>
> Matt
> On Oct 24, 2014 12:49 PM, "Adrian Cole" <adrian.f.cole@gmail.com
> <javascript:;>> wrote:
>
> > Hi, team.
> >
> > I feel the need to reiterate something, which may not impact everyone,
> but
> > should be taken into consideration nevertheless.
> >
> > jclouds is best a part of a platform. As a library, it needs to take care
> > not to make that impossible. Unlike some of our dayjobs, we cannot treat
> > jclouds as a monorepo or a monoculture, where we can assert a particular
> > version makes sense for us, then switch immediately to it.
> >
> > The idea of being runtime portable is a part of our legacy and played a
> > part in the large adoption jclouds had prior to entering the ASF.
> >
> > We've drifted from there. We moved to guava 17 in jclouds 1.8 without
> > analyzing the impact on our ecosystem. Core tools like jenkins weren't
> > consulted and may not work at all now. I'm willing to bet that many of
> the
> > apps
> > that use jclouds <https://jclouds.apache.org/community/users/> either
> > can't
> > work or were forced into a guava upgrade solely because we made them.
> >
> > Other platforms and potential integrations are even more difficult now.
> > For example, jclouds 1.8 is now incompatible with platforms from the
> last 3
> > companies I've worked at: Netflix, Square, and Twitter. While the ceiling
> > version is 16.0.1 across the three, there are some in the 14 range, and a
> > couple projects at 11!
> >
> > I asking, if not begging, to please not forget the legacy which in part
> led
> > us to where we are today. Please consider greatly the impact of runtime
> > portability.
> >
> > If guava makes jclouds impossible, jclouds is impossible. Please don't
> > force guava versions without thinking it through and asking diverse
> users,
> > or at least doing an industry poll on what is sustainable. It is really
> > burdensome to backport or revert this stuff, and we all have more
> important
> > work to do.
> >
> > In summary, we want to be known for making cloud easy, not making
> > dependency conflicts the norm.
> >
> > -A
> >
>

Re: Impact of racing towards the next guava

[Matt Stephenson <ma...@apache.org>]

+1

We shaded in guava for the appengine SDK, to try to get around this, which
lead to other problems...

Matt
On Oct 24, 2014 12:49 PM, "Adrian Cole" <ad...@gmail.com> wrote:

> Hi, team.
>
> I feel the need to reiterate something, which may not impact everyone, but
> should be taken into consideration nevertheless.
>
> jclouds is best a part of a platform. As a library, it needs to take care
> not to make that impossible. Unlike some of our dayjobs, we cannot treat
> jclouds as a monorepo or a monoculture, where we can assert a particular
> version makes sense for us, then switch immediately to it.
>
> The idea of being runtime portable is a part of our legacy and played a
> part in the large adoption jclouds had prior to entering the ASF.
>
> We've drifted from there. We moved to guava 17 in jclouds 1.8 without
> analyzing the impact on our ecosystem. Core tools like jenkins weren't
> consulted and may not work at all now. I'm willing to bet that many of the
> apps
> that use jclouds <https://jclouds.apache.org/community/users/> either
> can't
> work or were forced into a guava upgrade solely because we made them.
>
> Other platforms and potential integrations are even more difficult now.
> For example, jclouds 1.8 is now incompatible with platforms from the last 3
> companies I've worked at: Netflix, Square, and Twitter. While the ceiling
> version is 16.0.1 across the three, there are some in the 14 range, and a
> couple projects at 11!
>
> I asking, if not begging, to please not forget the legacy which in part led
> us to where we are today. Please consider greatly the impact of runtime
> portability.
>
> If guava makes jclouds impossible, jclouds is impossible. Please don't
> force guava versions without thinking it through and asking diverse users,
> or at least doing an industry poll on what is sustainable. It is really
> burdensome to backport or revert this stuff, and we all have more important
> work to do.
>
> In summary, we want to be known for making cloud easy, not making
> dependency conflicts the norm.
>
> -A
>