[CentOS-devel] SIGs, versions, and yum update

Wed Feb 10 16:36:41 UTC 2016
George Dunlap <dunlapg at umich.edu>

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?

 -George