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 Wed, 02 Apr 2014 21:38:24 GMT
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]
Sent: Wednesday, April 02, 2014 12:23 PM
To: user@jclouds.apache.org; 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?

/jd


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

There is a list of proposed changes to refactor neutron in jclouds-labs-openstack as detailed
here:
http://www.mail-archive.com/dev@jclouds.apache.org/msg04477.html

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.

Thanks!
Zack


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