<div dir="ltr">Hello,<div><br></div><div>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<br></div><div>and place it directly in repository (maybe even README?). I guess this is what your 3rd approach is about?</div><div><br></div><div>So, can we go with both?</div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 3, 2015 at 4:52 PM, Roman Prykhodchenko <span dir="ltr"><<a href="mailto:me@romcheg.me" target="_blank">me@romcheg.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi folks!<br>
<br>
<br>
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.<br>
<br>
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:<br>
<br>
1. Show deprecation warning for commands and parameters which are going to be different. Log deprecation warnings for deprecated library methods.<br>
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.<br>
<br>
2. Show the list o the deprecated stuff and planned changes on the first run. Then mute it.<br>
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.<br>
<br>
3. The same as #2 but publish the warning online.<br>
<br>
I personally prefer #2, but I’d like to get more opinions on this topic.<br>
<br>
<br>
References:<br>
<br>
1. <a href="https://blueprints.launchpad.net/fuel/+spec/re-thinking-fuel-client" target="_blank">https://blueprints.launchpad.net/fuel/+spec/re-thinking-fuel-client</a><br>
<br>
<br>
- romcheg<br>
<br>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>