qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] release retrospective, next release timing, numbering


From: Kevin Wolf
Subject: Re: [Qemu-devel] release retrospective, next release timing, numbering
Date: Mon, 7 May 2018 16:05:27 +0200
User-agent: Mutt/1.9.1 (2017-09-22)

Am 07.05.2018 um 07:33 hat Thomas Huth geschrieben:
> On 04.05.2018 19:30, Richard Henderson wrote:
> > On 05/04/2018 06:20 AM, Kevin Wolf wrote:
> >> I'm not sure what the exact systemd model is, but as we came to the
> >> conclusion that there is no semantic difference between major and minor
> >> version number for QEMU, I'd just merge them.
> >>
> >> This would result in 3.0 for the next release, 3.1 etc. would be stable
> >> releases, and the December release would be 4.0.
> >>
> >> It feels like the minimal change to fix our existing versioning scheme.
> > 
> > This is very similar to what GCC started to use at version 5.
> > 
> >     https://gcc.gnu.org/develop.html#num_scheme
> > 
> > I do think it makes sense to drop minor versions, leaving only major +
> > patchlevel (which then appears to be minor version).
> 
> We're currently also using the patch level for marking developing
> version (x.y.50) and release candidates (x.y.9r) ... we should also
> think of a way how we want to map that to a new numbering scheme. If we
> do it the GCC way, I guess the x.0 release will be the development
> "versions"? But the release candidates? Do we still need a third number
> for doing those (3.0.1 = rc1, 3.0.2 = rc2, ...)?

Nothing stops you from using 3.50, 3.91, etc. like we always did.

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]