Kamil,
thank you for the explanation.
Indeed, the idea of keeping two separate entry points — one for the old
functionality and another with the new cliff-based CLI makes more sense.
In addition to the advantages you mentioned it will allow us to avoid all the
mess with fall-backs and
Hi all,
IMHO deprecation warning should be added only to commands that we recently
changed (because users can switch to new interface when they see
deprecation error) or eventually solution #2 sounds ok but is not ideal
because people can forget about warning that they saw in previous release.
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
I’d like to resolve some questions:
@Przemysław:
- We can avoid that message by supplying --quiet.
- Changelog is currently managed automatically by PBR so as soon as there is a
release there will be a change log
- I think #2 can be done along with #3
@Kamil:
- The issue is that it’s not
@romcheg
- the idea is to switch partially to new client so keeping one package with
two entry points: fuel and fuel_v2. It will be convenient for us to add new
commands to fuel_v2 only and switch slowly old commands to new version and
add warnings in old client commands. It will give users time
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,
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
