[Top][All Lists]

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

Re: [Qemu-devel] [Xen-devel] [PATCH 0/3] Document intent for supported b

From: George Dunlap
Subject: Re: [Qemu-devel] [Xen-devel] [PATCH 0/3] Document intent for supported build platforms and bump min glib to 2.42
Date: Tue, 8 May 2018 16:47:48 +0100

On Tue, May 8, 2018 at 4:10 PM, Daniel P. Berrangé <address@hidden> wrote:
>> With my Xen maintainer hat on: I wouldn't feel justified, personally,
>> in asking another project to continue supporting older versions.  If
>> we didn't want to bump our own glib version, we would have to disable
>> "upstream" QEMU (as opposed to Xen's old qemu fork) for older versions
>> of glib.
> Or could you say that people need to use a stable version of QEMU ?
> eg users wanting Xen on RHEL-6, can use "upstream" QEMU, but they'll
> need to stick with the 2.12 stable branch version - not use git master
> or future releases. I guess it depends whether you can expect 2.12
> QEMU to carry on working correctly with ongoing Xen changes.

Yes, that's a good point.  In theory older versions of QEMU should in
theory continue working with newer versions of Xen.

Two points about that solution:

1. Our release tarball currently ships with a snapshotted version of a
specific version of QEMU, and if you check out a release tag in our
git repo it will by default clone a specific version of qemu for you.
Users / downstreams would have to disable that and clone their own

2. While in theory all versions should continue to work, in practice
our testing system and the majority of our downstreams use the version
specified by the release, even when they build QEMU separately.  (I
think Debian may be an exception to this rule but I'm not sure.)
Using an older version of QEMU does mean going "off the beaten track"
a bit, increasing slightly the chance of random bugs.

Anyway, from what I can tell, your decision sounds entirely
reasonable, and users and downstreams who don't want to / can't update
glib have a number of options, so I personally don't see any grounds
for objecting or complaining.  Thanks again for the heads-up.


reply via email to

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