Note that the changes just make jclouds compatible with Guice 4, but don't change the Guice version we use. jclouds will still use Guice 3, but will be runtime compatible with Guice 4, if users want to use a newer version. Something similar to what we do with Guava.
I've already configured a vuild that uses Guice 4 [1] that is currently tracking the PR branch, but we'll add it to track master if the PR gets merged (or we could add Guice to the version matrix we have in the Guava compatibility builds). In any case, the fix does not change the Guice version; just makes the code Guice 4 friendly. [1] https://jclouds.ci.cloudbees.com/view/public/job/jclouds-guice-4/ On 20 July 2015 at 23:34, Andrew Phillips <andr...@apache.org> wrote: >> Please, share your thouhts here or in the PR! > > > Given the struggles we've had in the past around forcing newer Guice > versions on users, my default inclination here would be to stay with the > older version if there are still users on this: if the problem we're trying > to solve isn't critical, we don't want to force users to upgrade their Guice > versions just for jclouds' sake. > > The most important data points in my mind would thus be: > > * how critical is the issue we're trying to solve here? Is there a > workaround that users can apply? > * how many users are still on our current Guice version, vs. the proposed > new version? > > Do we have any good data on either of these points? > > Thanks for bringing this up, Ignasi! > > > ap
