From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LrYGi-0006hW-H4
	for qemu-devel@nongnu.org; Wed, 08 Apr 2009 09:56:44 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LrYGe-0006fo-4m
	for qemu-devel@nongnu.org; Wed, 08 Apr 2009 09:56:44 -0400
Received: from [199.232.76.173] (port=47304 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LrYGd-0006fb-TE
	for qemu-devel@nongnu.org; Wed, 08 Apr 2009 09:56:39 -0400
Received: from mail2.shareable.org ([80.68.89.115]:53974)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <jamie@shareable.org>) id 1LrYGd-0001x6-9r
	for qemu-devel@nongnu.org; Wed, 08 Apr 2009 09:56:39 -0400
Date: Wed, 8 Apr 2009 14:56:34 +0100
From: Jamie Lokier <jamie@shareable.org>
Subject: Re: [libvirt] Re: [Qemu-devel] Changing the QEMU svn VERSION string
Message-ID: <20090408135634.GA3841@shareable.org>
References: <49DABC83.7010608@codemonkey.ws> <49DB5AAE.8050205@codemonkey.ws>
	<20090407175844.GA17004@caradoc.them.org>
	<200904072336.41097.paul@codesourcery.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200904072336.41097.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
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.gnu.org/pipermail/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: qemu-devel@nongnu.org
Cc: libvir-list@redhat.com, Gerd Hoffmann <kraxel@redhat.com>, kvm-devel <kvm@vger.kernel.org>

Paul Brook wrote:
> I'm extremely sceptical of anything that claims to need a fine
> grained version number. In practice version numbers for open source
> projects are fairly arbitrary and meaningless because almost
> everyone has their own set of patches and backported fixes anyway.

I find it's needed onlyh when you need to interact with a program and
workaround bugs or temporarily broken features, and also when the
program gives no other way to determine its features.  For some
reason, I find kernels are the main thing this matters for...

If the help text, some other output, or an API gives enough
information for interacting programs to know what to do, that's much
better and works with arbitrary patches etc.

-- Jamie