jclouds-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Gaul <g...@apache.org>
Subject Re: DigitalOcean v2 to 1.9.x
Date Sun, 28 Jun 2015 03:18:04 GMT
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
View raw message