From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50189) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6MNH-0002MT-Iu for qemu-devel@nongnu.org; Mon, 05 Aug 2013 11:07:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V6MNB-0006nl-JB for qemu-devel@nongnu.org; Mon, 05 Aug 2013 11:07:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51869) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6MNB-0006nf-A8 for qemu-devel@nongnu.org; Mon, 05 Aug 2013 11:07:01 -0400 Message-ID: <51FFBF86.5030802@redhat.com> Date: Mon, 05 Aug 2013 17:06:46 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <1375701492-21759-1-git-send-email-peter.maydell@linaro.org> <20130805124922.GA5108@redhat.com> <87ob9cz2p9.fsf@codemonkey.ws> <20130805134915.GE5108@redhat.com> <87y58gp6q5.fsf@codemonkey.ws> In-Reply-To: <87y58gp6q5.fsf@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Versioned machine types for ARM/non-x86 ? (Was Re: [PATCH v4 0/2] ARM: add 'virt' platform) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Peter Maydell , "Mian M. Hamayun" , patches@linaro.org, qemu-devel@nongnu.org, Markus Armbruster , kvmarm@lists.cs.columbia.edu Hi, >>> However, unlike PC, I'd like to do linear versioning and avoid bumping >>> at every release. >>> >>> IOW, spapr-1, spapr-2, spapr-3, etc. >>> >>> I think virt ought to try to do the same. >> >> Any particular reason why ? I kind of like the clarity of having the >> version match the release version. Avoids needing to lookup a magic >> decoder ring to figure out which QEMU version maps to which machine >> version. +1, /me likes the version-based naming too. It's also easier to handle on source code level as it makes it easier to reuse the #defines we already have for pc compat properties. > (1) reduces testing matrix by having fewer versions I doubt that is going to fly. It's not like we do new pc-* machine types just for the snake of creating them, there is no policy we have to have a new one for each release. Usually we create them in case there is an actual need, i.e. a incompatible change which needs a compat property. Which so far was the case for (almost?) every release. > (2) makes people > think more carefully about whether it's really necessary to break > compatibility. Often it's not about incompatibilities but about new features which we wanna have enabled by default. cheers, Gerd