Open Stack

Thanks Steve, that’s exactly what I wanted to know!

—ruby

From: Steve Martinelli <s.martinelli at gmail.com<mailto:s.martinelli at gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Thursday, May 12, 2016 at 12:05 PM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [ironic][openstackclient] deprecation process

I thought we had this written down somewhere but I can't find it. The OSC deprecation process is two major releases. So if something was deprecated in L, it is removed in N. This goes for optional parameters being renamed / dropped, or commands being dropped / renamed.

If an optional parameter is being deprecated (say --tenant in favor of --project), then we usually add a mutually exclusive group for these, and force the user to only pick one, log a deprecation message if they pick the wrong one, and suppress the help text of the old option. See [1] for an example

If a command is being deprecated it's a bit easier, just log a deprecation message and remove it. If it is being renamed then you can also have it subclass the new command.

As always, the deprecation message should indicate which command / option to use.

[1] https://github.com/openstack/python-openstackclient/blob/b4c3adbd308e65679489c4c64680cbe0324f4bc7/openstackclient/volume/v1/volume.py#L53-L63

On Thu, May 12, 2016 at 9:46 AM, Loo, Ruby <ruby.loo at intel.com<mailto:ruby.loo at intel.com>> wrote:
Hi OpenStackClient folks,

Ironic is following the standard deprecation process [1]. We added an OSC plugin and realized that we didn’t get the commands quite right. This patch [2] adds the right commands and deprecates the wrong ones. My question is what the deprecation process might be. Since it is a plugin to OSC, should it follow OSC’s deprecation process and if so, what might that process be? Or since the commands are related to ironic, should it follow ironic’s deprecation process? In particular, I wanted to know how long should/must we support those deprecated commands.

For the user’s sake, it seems like it would make sense that all OSC (plugin or not, does the user know the difference?) commands follow the same deprecation policy.

I took a quick look and didn’t see anything documented about this, so I might have missed it.

What sez you?

—ruby

[1] https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html
[2] https://review.openstack.org/#/c/284160


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160516/6b0a002f/attachment.html>