On Fri, 2020-10-30 at 07:02 -0400, Matt Coleman wrote: > Hello, > > I've been getting familiar with Hyper-V recently and have gotten > stymied by inconsistencies in its API. > > While Hyper-V has V1 and V2 APIs, neither one is consistent between > Windows versions. For example... > * Windows 2012 only supports a subset of the V2 API > * Windows 2012 implements some V1 functions differently than 2008R2 > * Windows 2016 broke compatibility with 2012R2 by replacing some classes > > Some of these differences are undocumented, too, which is just lovely. > > Most of these changes are relatively easy to handle, but the > differences between 2008R2's and 2012's implementations of the V1 API > result in libvirt code with a lot of conditionals containing obscure > format strings in the 2008R2 blocks. > > Windows 2008R2's extended support ended January 14, 2020: > https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2008-r2 > > Windows 2012's mainstream support ended in 2018, but it still has > extended support through October 10, 2023: > https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2012 > > Since 2008R2 is no longer supported by Microsoft, I propose removing > support for it from libvirt. Dropping 2008R2 support is a no-brainer. Can we got further? Our policy[1] for Linux is The project aims to support the most recent major version at all times. Support for the previous major version will be dropped 2 years after the new major version is released or when the vendor itself drops support, whichever comes first. If we adopted the same policy for Windows Server[2], then we could drop support for 2012R2 today and support for 2016 in the next release. Is there a good reason why we should *not* do that? [1] https://libvirt.org/platforms.html [2] https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions#Server_versions -- Andrea Bolognani / Red Hat / Virtualization
