[...] >> I understand QEMU is just but one variable in the complex equation. >> Listing QEMU was just an example for this series based on the 8 years >> since 0.12 which is the minimum we support now vs. 5 years since 1.3 >> which is where this series was headed. Using the 2-3 years you responded >> in other threads would bring us to QEMU 2.2 or even 2.5. > > Not sure how you get to 2.2 ? Even if we drop RHEL-6, RHEL-7 ships 1.5.3 > version of QEMU. > It's the always troubling multiple factor equation. My eyes/brain dropped the "overlapping" in the other thread's comment: "This is a sign that instead of saying 2 major releases, we should instead define "NN" years of overlapping support for a value of NN that is 2 or 3." If we went strict 3 years on QEMU support it's 2.2, but throw RHEL7 into the equation it's 1.5 (almost 5 years old). When/if any OS release train starts moving faster, we could have a whole lot of interesting decisions. Still keeping track of which QEMU went into which RHEL (or SLES or Debian or ...) is not something I keep in the short or long term memory 0-). John -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
