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 <m...@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-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
