From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=60097 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Ou5NR-0005e8-MP
	for qemu-devel@nongnu.org; Fri, 10 Sep 2010 11:18:58 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <kwolf@redhat.com>) id 1Ou5NQ-00007H-Jg
	for qemu-devel@nongnu.org; Fri, 10 Sep 2010 11:18:57 -0400
Received: from mx1.redhat.com ([209.132.183.28]:37749)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <kwolf@redhat.com>) id 1Ou5NQ-00007B-Bk
	for qemu-devel@nongnu.org; Fri, 10 Sep 2010 11:18:56 -0400
Message-ID: <4C8A4C61.2030905@redhat.com>
Date: Fri, 10 Sep 2010 17:18:57 +0200
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format
References: <4C86BC6B.5010809@codemonkey.ws> <4C874812.9090807@redhat.com>
	<4C87860A.3060904@codemonkey.ws> <4C888287.8020209@redhat.com>
	<4C88D7CC.5000806@codemonkey.ws> <4C8A1311.8070903@redhat.com>
	<4C8A15C4.40201@redhat.com>
	<AANLkTi=tt+Zh_i15LFz36kOdD8sFBKpJ2wsPRGM=3zkV@mail.gmail.com>
	<4C8A19CA.3040000@redhat.com> <4C8A3106.8050501@codemonkey.ws>
	<20100910134859.GB28831@lst.de> <4C8A488B.2090907@codemonkey.ws>
In-Reply-To: <4C8A488B.2090907@codemonkey.ws>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@gmail.com>, Christoph Hellwig <hch@lst.de>, Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>, Avi Kivity <avi@redhat.com>

Am 10.09.2010 17:02, schrieb Anthony Liguori:
> What makes us future proof is having a good feature support.  qcow2 
> doesn't have this.  We have a good way at making purely informational 
> changes and also making changes that break the format.  Those features 
> are independent so they can be backported in a compatible way too.

I might have agreed that it's useful to be able to backport them
independently if we had had lots of such features added in the past. But
we haven't.

The qcow2 mechanism for compatible changes is header extensions (used
exactly once, for the backing file format) and for incompatible changes
increasing the version number (never used so far, if you consider qcow1
and qcow2 completely independent formats, which I think they are).

Kevin