Maybe add a Changelog in the repo and maintain it? http://keepachangelog.com/
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. P. 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. https://blueprints.launchpad.net/fuel/+spec/re-thinking-fuel-client > > > - romcheg > > > > __________________________________________________________________________ > 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 > __________________________________________________________________________ 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
