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 >> > >>
