Thanks Steve, that’s exactly what I wanted to know! —ruby
From: Steve Martinelli <s.martine...@gmail.com<mailto:s.martine...@gmail.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Thursday, May 12, 2016 at 12:05 PM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@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....@intel.com<mailto:ruby....@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
