Open Stack

Hello,

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 [1] 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
> different.
>
> 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
> upgrade.
>
> 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.
>
>
> References:
>
> 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
> 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/20150303/7000b454/attachment.html>