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.
