Re: [PATCH 0/7] python: create installable package

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

On 6/17/20 10:27 PM, John Snow wrote:
> 
> 
> On 6/17/20 3:52 PM, Cleber Rosa wrote:
>> On Tue, Jun 02, 2020 at 08:15:16PM -0400, John Snow wrote:
[...]
>> Are you proposing that we have, say, "python-qemu" version 10, being
>> the 10th API version, without any regard to the QEMU version
>> supported?  Or version 10.5.3 would mean 10th API version, intended
>> to support QEMU 5.3?
>>
> 
> I am proposing only that we use semver to track the API version of the
> SDK itself.
> 
> So that could be:
> 
> A) 1.x, 2.x, 3.x (etc) with absolutely no connection to the intended
> QEMU support version. It either works or it doesn't. It might not work
> very spectacularly. Major semver bumps indicate a breaking change to the
> library API.

Major changes occurs between QEMU releases. If there is no QEMU release,
it is pointless to release the python-qemu package, right?

> 
> B) 1.5.0.0, 1.5.1.0, 1.5.2.0 (etc) where the major version still
> describes the API, but the remainder of the version describes the
> intended target QEMU.
> 
> Or, we could do:
> 
> C) 5.0.0, 5.1.0, 5.2.0, etc. where it tracks the QEMU version verbatim,
> end of story.

At least it KISS.

> 
> I don't like (C) very much, because it violates some prevailing idioms
> about python package versioning. A or B seem better, but do run us into
> potential trouble with people having mismatched versions.

Which is why I prefer (C).

> 
> I'd take A or B. (B) is a little chatty but gives some good information
> and allows you to pin versions effectively, so I think I'm leaning
> towards that one right now.
> 
> Well, whatever we do right now, I think I do really want to make sure we
> are publishing under 0.x to really give the illustration that we are NOT
> promising even the illusion of stability right now.