[openstack-dev] [Fuel] Deprecation warnings in python-fuelclient-6.1.*
dshulyak at mirantis.com
Tue Mar 3 21:53:56 UTC 2015
I would vote for 2nd, but i also think that we can generate same
information, on merge for example, that will be printed during first run
and place it directly in repository (maybe even README?). I guess this is
what your 3rd approach is about?
So, can we go with both?
On Tue, Mar 3, 2015 at 4:52 PM, Roman Prykhodchenko <me at romcheg.me> wrote:
> Hi folks!
> According to the refactoring plan  we are going to release the 6.1
> version of python-fuelclient which is going to contain recent changes but
> will keep backwards compatibility with what was before. However, the next
> major release will bring users the fresh CLI that won’t be compatible with
> the old one and the new, actually usable IRL API library that also will be
> The issue this message is about is the fact that there is a strong need to
> let both CLI and API users about those changes. At the moment I can see 3
> ways of resolving it:
> 1. Show deprecation warning for commands and parameters which are going to
> be different. Log deprecation warnings for deprecated library methods.
> The problem with this approach is that the structure of both CLI and the
> library will be changed, so deprecation warning will be raised for mostly
> every command for the whole release cycle. That does not look very user
> friendly, because users will have to run all commands with --quiet for the
> whole release cycle to mute deprecation warnings.
> 2. Show the list o the deprecated stuff and planned changes on the first
> run. Then mute it.
> The disadvantage of this approach if that there is a need of storing the
> info about the first run to a file. However, it may be cleaned after the
> 3. The same as #2 but publish the warning online.
> I personally prefer #2, but I’d like to get more opinions on this topic.
> 1. https://blueprints.launchpad.net/fuel/+spec/re-thinking-fuel-client
> - romcheg
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev