Frantisek Zatloukal wrote:
On Thu, Jul 20, 2023 at 11:58 AM Peter Robinson
<pbrobinson(a)gmail.com>
wrote:
> You can evolve APIs with versioning to ensure backwards compatibility
> while also evolving the usecases.
Well, this is exactly the case, isn't it? You have dnf4/dnf5, all nice and
versioned.
It is not. Versioning would mean DNF 5 would support both the DNF 4 and the
DNF 5 API in parallel, e.g., with namespaces (e.g., import dnf4 vs. import
dnf5 in Python), prefixed symbol names (e.g., dnf4_* vs. dnf5_* in any
programming language, even in C where namespaces are not natively
supported), or ELF symbol versioning (but that makes it hard to compile
against the compatibility API, symbol versioning is mostly designed for
runtime binary compatibility), so that code using the DNF 4 API would still
get the DNF 5 implementation for free, with no porting effort.
What you are doing is providing a compatibility library, which should be the
minimum standard when a library breaks binary compatibility (because
otherwise everything not yet ported will just be broken), but is not the
same as actually providing versioned APIs in the library.
Kevin Kofler