jclouds-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Turli <andrea.tu...@gmail.com>
Subject Re: DigitalOcean v2 to 1.9.x
Date Tue, 30 Jun 2015 21:42:42 GMT
Personally I've always consider jclouds-labs as a common repo for the labs
repos, so in my mind this implicit dependency has always been there.
Moreover, the recent changes to OAuth made this provider certainly useful
to many other providers, not only Google's, so I think it should go to
jclouds-labs.

My two cents,
Andrea

On Sun, Jun 28, 2015 at 9:00 AM Ignasi Barrera <nacx@apache.org> wrote:

> If we move oauth to the jclouds-labs then there is no practical build order
> change, as we (our relesse scripts, our Jenkins build chain) always build
> jclouds-labs first.
>
> I'd like 2.0.0 to be feature driven instead of having a fixed dste for it:
> we need docker, azure and google properly promoted in it, and also
> DigitalOcean (it's been stable for ages in the v1 and having it incubating
> in 1.9.1 would allow us to promote it with confidence) and ideally
> CloudSigma2 and ProfitBricks.
>
> Also support for Guice 4 has been requested and I think 2.0.0 should be
> compatible.
>
> I really think we can't fix a date for 2.0.0 if we want to be able to ship
> all that, and other important stuff, in it.
> El 28/6/2015 5:18, "Andrew Gaul" <gaul@apache.org> escribió:
>
> > Theoretically I dislike changing the build order although practically
> > this has no impact.  Will defer to whoever does the backport.  What if
> > we accelerate the 2.0.0 release to avoid doing major surgery on the
> > release branch?  We average a major release about every 7 months:
> >
> > 1.6.0/  27-Apr-2013
> > 1.7.0/  23-Dec-2013
> > 1.8.0/  05-Aug-2014
> > 1.9.0/  29-Mar-2015
> >
> > But instead we could plan 2.0.0 for August or September, 5 or 6 months.
> > This would give DO users a few months lead time.
> >
> > On Sun, Jun 28, 2015 at 12:04:42AM +0200, Ignasi Barrera wrote:
> > > Hi!
> > >
> > > We're about to open PRs to merge the DigitalOcean v2 provider. Since
> > > the v1 version will no longer be available starting on November [1]
> > > (and is the only one we support now), I think we should include the v2
> > > provider in 1.9.1. This will give users enough time to migrate and
> > > test the new API (there are no breaking changes in it) before it is
> > > shut down.
> > >
> > > Before doing that, we have to agree how to proceed with its OAuth
> > > dependency. DigitalOcean v2 depends on the OAuth API, which was
> > > promoted to the main repo but only in 2.0.0, to avoid a groupId
> > > change; in 1.9.x the oauth home is in the jclouds-labs-google repo.
> > > This gives us the following options:
> > >
> > > * Merge the digitalocean2 provider in jclouds-labs, and change the
> > > "build order". jclouds-labs-google will have to be built before
> > > jclouds-labs.
> > > * Move the oauth api to jclouds-labs, and then merge digitalocean2
> > > there. This implies that jclouds-labs-google will need to be built
> > > after jclouds-labs, but that's what we are already doing implicitly.
> > >
> > > The main issue here is that we are introducing a dependency between
> > > labs repos we don't have now, but I think that having the DO v2
> > > provider in 1.9.1 is worth it.
> > >
> > > WDYT?
> > >
> > > if there is an agreement to proceed, I'd vote for option 2 (move oauth
> > > then merge the provider).
> > >
> > > Take into account that there are no references to 'google' in ithe
> > > OAuth api; it is just hosted in the labs-google repo. This means most
> > > users won't be affected, as the Maven coordinates won't change.
> > >
> > >
> > > I.
> > >
> > >
> > >
> > >
> > > [1]
> >
> https://developers.digitalocean.com/documentation/changelog/api-v1/sunsetting-api-v1/
> >
> > --
> > Andrew Gaul
> > http://gaul.org/
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message