[CentOS-virt] Xen Version update policy

Thu Nov 28 18:12:04 UTC 2019
George Dunlap <dunlapg at umich.edu>

Hey all,

This mail has been a long time in coming, but with the upcoming
expiration of security support for Xen 4.8, it's time to start thinking
about what our update policy will be for the Xen packages in general.

Citrix is committed to officially supporting one Xen version at a time
through the CentOS Virt SIG.  (Others in the community are welcome to
support others.)  But we'd like input as to which version the community
would like to be supported at any one time.

Please express your opinion on each option by replying as follows:
-2: This is a bad idea, and I would argue against this
-1: I'm not happy with this, but I wouldn't argue against this.
0: No opinion.
1: I'm happy with this, but I wouldn't argue for it.
2: This is a great idea, and I'd argue for it.

There are several possible options:

1. Always support the newest option.  This means we get all the newest
features from Xen in the Virt SIG by default; but also means we get all
the newest bugs.

1a. Always support the newest option once it has at least one point
release.  This balances the newness with a bit of extra testing.

1b. Always support the second-to-newest version (e.g., when 4.13 comes
out, switch to 4.12.x)

2. Always support the oldest security-supported version.  This means we
get the most stable version of Xen; but it does mean it is several years
behind as far as features go.  It also means that further bugfixes do
not happen automatically, and further bugs found will need to be

3. Always support the oldest fully-supported version.  Reasonably
stable, reasonably old, still gets bugfixes.

4. Support a version until it's out of security support, then jump to
the newest version.  This minimizes the number of upgrades required
(although may make each upgrade more painful).

4a.  Support a version until it's out of full support, then jump to the
newest version.

Any other options?

For my part, I think 1a, 1b, and 3 are all reasonable options.

-George