On Wed, Feb 10, 2016 at 11:00 AM, George Dunlap dunlapg@umich.edu wrote:
On Wed, Feb 10, 2016 at 4:36 PM, George Dunlap dunlapg@umich.edu wrote:
A couple of weeks ago I was just about to push an update of Xen 4.4 to Xen 4.6 to the Virt SIG repositories, and I suddenly got some push-back from the users, because Xen 4.6 has some fairly significant changes -- particularly the removal of the old toolstack daemon called xend. (xend had been disabled by default and had lots of messages warning about the upcoming deprecation, even in 4.4.)
It seems some users have the expectation that they should be able to run "yum update -y" on their servers on a regular basis, without having to worry about accidentally updating to a new major version that break things.
So one thing that was proposed was that we make separate packages somehow, such that users would have to actively request the newer version rather than getting it automatically. (This could be done either by having a package named xen46, or by having separate centos-release-xen-46 package that pointed to an entirely different repository.)
But of course, other users pushed back on that idea, saying they would always rather have the latest version Just Work, and didn't like the idea of having to manually keep track of what version was installed on any given system, or of actually finding out that there's a new package and what that new package name is.
KB and I chatted about it at the Virt SIG meeting, and decided that we should touch base with the other SIGs to have a consistent message.
As for my own opinion: I can see both sides of the story, and as a package maintainer I'd be willing to do either one.
But on the whole I tend to side with the "latest version" crowd. I think you should always be looking at what "yum update" gives you before installing it; even minor updates I can't guarantee are going to break things. And I'd rather the installation instructions be simple (don't have to mess around with version numbers), and I'd rather people not have to fish around for major updates (or run packages with unpatched security vulnerabilities because they didn't realize their packages were now obsolete).
What do other SIGs think?
Splitting the difference from a user point of view, here's another option:
- Have a separate repo for each major version
- Have the centos-release-xen-NN packages which always point to a specific repo
- Have the centos-release-xen package always point to the most recent repo
This is a tiny bit more infrastructure work, but makes it easier to test both minor releases and major releases; it also makes it easier for volunteers to step up and maintain older versions if they want.
+1 to this idea