qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a


From: Kevin Wolf
Subject: Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces)
Date: Thu, 9 Mar 2017 17:00:07 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Am 08.03.2017 um 09:26 hat Thomas Huth geschrieben:
> what will be the next version of QEMU after 2.9? Will we go for a 2.10
> (as I've seen it mentioned a couple of times on the mailing list
> already), or do we dare to switch to 3.0 instead?
> 
> I personally dislike two-digit minor version numbers like 2.10 since the
> non-experienced users sometimes mix it up with 2.1 ... and there have
> been a couple of new cool features in the past releases that would
> justify a 3.0 now, too, I think.

We never really defined what major version numbers meant (except
"Anthony felt like using a new one"), so it's kind of arbitrary and we
could decide either way.

I don't think double digit minor version numbers make the switch
necessary, though. We went up to 0.15 before without any problems.

When this was discussed in IRC a while ago, the consensus seemed to be
2.10, so that's what I've been talking about since then - and from what
I read, it seems most other people are still expecting the same.

> But anyway, the more important thing that keeps me concerned is: Someone
>  once told me that we should get rid of old parameters and interfaces
> (like HMP commands) primarily only when we're changing to a new major
> version number. As you all know, QEMU has a lot of legacy options, which
> are likely rather confusing than helpful for the new users nowadays,
> e.g. things like the "-net channel" option (which is fortunately even
> hardly documented), but maybe also even the whole vlan/hub concept in
> the net code, or legacy parameters like "-usbdevice". If we switch to
> version 3.0, could we agree to remove at least some of them?

If we want to go this way, maybe this would actually be an argument for
doing a 2.10 first to give people enough time to think about any
incompatible changes they would like to make and then do 3.0 one release
later.

Kevin



reply via email to

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