On Mon, Jul 27, 2009 at 10:18:18PM +0100, Daniel P. Berrange wrote: > It is also probably worth formalizing how long we wish to support a > particular hypervisor release series for. > > ie how long do we wish to support Xen 3.0.3 for (for benefit of > RHEL-5) before we declare only Xen 3.1.0 or later & thus drop > all the crufty xm_internal.c code. > > As a starting point I'd say we should support a particular HV > release for as long as it is shipped in the current release of > a major distro. ie we'd support Xen 3.0.3 for as long as RHEL-5 > was most recent, and once RHEL-6 came out we'd drop Xen 3.0.3 > support, picking the next oldest Xen version that's used in a > current major distro whether that's 3.1.0 or 3.3.0 or something > else. This would allow distro maintainers reasonably easy > backports and/or rebases to newer libvirt versions for some > amount of time, without burdening us (upstream) to support ancient > versions of Xen / QEMU forever. This thread is probably not the best place to discuss that policy, and should be started separately. I tend to think that it depends how intrusive the specific bits are to manage an old hypervisor version. If it doesn't hurt, except for the size IMHO there is no reason to drop support, it's only if the associated code makes maintainance harder than necessary that it should be dropped. For example in xm_internal.c case as long as it's cleanly separated and doesn't make patches for new versions more complex, I would keep it. Another example is old Xen hypervisor code, we have that big detection code and switch but beside that it's not making other things any more complex. The goal of libvirt being really to decouple from low level changes and simplify long term maintainance, I would be very conservative and drop ancien versions support only if it really gets painful and we are pretty sure there is no real users left. I consider the project users the final users, not the distro maintainers ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list