Maybe add a Changelog in the repo and maintain it?

Option #2 is OK but it can cause pain when testing -- upon each fresh
installation from ISO we would get that message and it might break some
tests though that is fixable. Option #3 is OK too. #1 is worst and I
wouldn't do it.

Or maybe display that info when showing all the commands (typing 'fuel'
or 'fuel -h')? We already have a deprecation warning there concerning
client/config.yaml, it is not very disturbing and shouldn't break any
currently used automation scripts.


On 03/03/2015 03:52 PM, Roman Prykhodchenko 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.
> - romcheg
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:

OpenStack Development Mailing List (not for usage questions)

Reply via email to