You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Jeremy Daggett <je...@gmail.com> on 2014/04/02 19:23:25 UTC
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 <za...@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
RE: neutron refactoring - breaking changes
Posted by Zack Shoylev <za...@RACKSPACE.COM>.
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:
org.jclouds.openstack.neutron.v2_0.*
org.jclouds.openstack.neutron.v2.*
... and then deprecate the v2_0 one in 1.8, to be removed in jclouds 2.0? WDYT?
/jd
On Wed, Apr 2, 2014 at 2:38 PM, Zack Shoylev <za...@rackspace.com>> wrote:
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<ma...@gmail.com>]
Sent: Wednesday, April 02, 2014 12:23 PM
To: user@jclouds.apache.org<ma...@jclouds.apache.org>; dev@jclouds.apache.org<ma...@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 <za...@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
RE: neutron refactoring - breaking changes
Posted by Zack Shoylev <za...@RACKSPACE.COM>.
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:
org.jclouds.openstack.neutron.v2_0.*
org.jclouds.openstack.neutron.v2.*
... and then deprecate the v2_0 one in 1.8, to be removed in jclouds 2.0? WDYT?
/jd
On Wed, Apr 2, 2014 at 2:38 PM, Zack Shoylev <za...@rackspace.com>> wrote:
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<ma...@gmail.com>]
Sent: Wednesday, April 02, 2014 12:23 PM
To: user@jclouds.apache.org<ma...@jclouds.apache.org>; dev@jclouds.apache.org<ma...@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 <za...@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
Re: neutron refactoring - breaking changes
Posted by Jeremy Daggett <je...@gmail.com>.
Hi Zack,
Just to make this clear, we would have both packages:
org.jclouds.openstack.neutron.v2_0.*
org.jclouds.openstack.neutron.v2.*
... and then deprecate the v2_0 one in 1.8, to be removed in jclouds 2.0?
WDYT?
/jd
On Wed, Apr 2, 2014 at 2:38 PM, Zack Shoylev <za...@rackspace.com>wrote:
> 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
> <ma...@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
>
>
Re: neutron refactoring - breaking changes
Posted by Jeremy Daggett <je...@gmail.com>.
Hi Zack,
Just to make this clear, we would have both packages:
org.jclouds.openstack.neutron.v2_0.*
org.jclouds.openstack.neutron.v2.*
... and then deprecate the v2_0 one in 1.8, to be removed in jclouds 2.0?
WDYT?
/jd
On Wed, Apr 2, 2014 at 2:38 PM, Zack Shoylev <za...@rackspace.com>wrote:
> 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
> <ma...@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
>
>
RE: neutron refactoring - breaking changes
Posted by Zack Shoylev <za...@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]
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 <za...@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
RE: neutron refactoring - breaking changes
Posted by Zack Shoylev <za...@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]
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 <za...@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