On Mon, 2019-04-29 at 20:45 +0000, Zbigniew Jędrzejewski-Szmek wrote:
That's a very unfortunate situation. The API change is a clear
breakage of the Update guidelines. The version bump that is done in
the patch 0.28.1 → 0.29.0 is also wrong, since this number also
describes the python API, and changes that remove names need to bump
the major number to signal backwards incompatibility.
The least-bad solution would be to add back something in the python
API to restore compatibility. Some feedback from the dnf side whether
this is possible would be very useful.
+1 to this whole thread. For the record, and just to be clear, the
backwards-incompatible change here was *not* the thing we needed to fix
the release-blocking upgrade bug. It just came along for the ride. DNF
team's current practice seems to be to not use stable branches, but
simply keep all development for libdnf and dnf in a single stream,
constantly cut releases of them, and send those releases out as updates
to all Fedora versions.
DNF team, *this is not sustainable*. It is clearly leading to
problematic violations of the Fedora packaging guidelines like this.
Now DNF is in RHEL 8, you are *definitely* going to start hearing about
this from RHEL stakeholders, because this is very definitely not how
things work on RHEL either.
You must either stop making API-breaking changes or start using stable
branches so non-API-breaking fixes can be sent out to stable distros
without disruptive changes. It is just not acceptable to tie needed
bugfixes to API changes in this way.
I also find it significant that libdnf still has, so far as I can tell,
absolutely no interface documentation -
links to "the hawkey
documentation page", which is obviously wildly outdated at this point -
and that this API-breaking change was not even mentioned in the libdnf
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net