+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" <andrew.ba...@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 <inbar...@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 <matts...@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.c...@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 > >> > > >> >
