jclouds-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zack Shoylev <zack.shoy...@RACKSPACE.COM>
Subject RE: neutron refactoring - breaking changes
Date Thu, 03 Apr 2014 15:23:01 GMT
Hi Jeremy,

That is exactly what I am suggesting, yes.

My initial reaction was that this would be very confusing, however, with the right deprecation
messages it should be ok.

From: Jeremy Daggett [jeremy.daggett@gmail.com]
Sent: Thursday, April 03, 2014 8:44 AM
To: dev@jclouds.apache.org
Cc: user@jclouds.apache.org
Subject: Re: neutron refactoring - breaking changes

Hi Zack,

Just to make this clear, we would have both packages:


... and then deprecate the v2_0 one in 1.8, to be removed in jclouds 2.0? WDYT?


On Wed, Apr 2, 2014 at 2:38 PM, Zack Shoylev <zack.shoylev@rackspace.com<mailto:zack.shoylev@rackspace.com>>
I would hold off on separate renaming PRs and here is why:

One of the best ways to deprecate the existing neutron implementation is to deprecate it while
having an alternative namespace with the refactored one. (deprecate and and add the refactored
neutron in the same commit).  So this would be my suggestion.

From: Jeremy Daggett [jeremy.daggett@gmail.com<mailto:jeremy.daggett@gmail.com>]
Sent: Wednesday, April 02, 2014 12:23 PM
To: user@jclouds.apache.org<mailto:user@jclouds.apache.org>; dev@jclouds.apache.org<mailto:dev@jclouds.apache.org>
Subject: Re: neutron refactoring - breaking changes

Hi Zack,

I feel that we should also change the Java package namespace as a part of this refactoring.
 It does not follow the standard OpenStack API naming convention and their additive progression
from API release to release.

All OpenStack APIs should be referenced with a major version only: "v2" versus "v2_0"

That said, I suggest that we do this refactoring now, to unify the OpenStack version numbers
across jclouds.  The package namespace should change from:

"org.jclouds.openstack.neutron.v2_0" -> "org.jclouds.openstack.neutron.v2"

In my experience with the APIs over the past several years, "v2_0" doesn't really mean anything
to me and it ties the implementation to a specific version. APIs are additive, so "v2.2" is
still the "v2" API with new features/additions.

I would be more than happy to submit a PR to make this happen. We also should do this with
the other incubating Glance APIs and any future work with OpenStack.

Comments, questions, concerns?


On Tue, Apr 1, 2014 at 8:47 AM, Zack Shoylev <zack.shoylev@rackspace.com<mailto:zack.shoylev@rackspace.com><mailto:zack.shoylev@rackspace.com<mailto:zack.shoylev@rackspace.com>>>

There is a list of proposed changes to refactor neutron in jclouds-labs-openstack as detailed

I would like to hear back from users who are currently using the API - is this something we
should or should not be doing? The problem is that we do not have a "happy" deprecation path
for these changes. One good suggestion I've heard so far was to deprecate in 1.7 and put the
breaking changes in 1.8.


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