On 10 February 2016 at 10:00, George Dunlap <dunlapg at umich.edu> wrote: > On Wed, Feb 10, 2016 at 4:36 PM, George Dunlap <dunlapg at 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. If this is possible to do tooling wise then I would say this is your "best" bet. However, if this is too much of a headache, then I would stick with the latest push for multiple reasons: 1) People will assume you are still supporting/fixing 4.4 even when it is not happening. 2) Sites which need extra stability that this problem showed need to be aware this could have happened even in a 4.4.5 to 4.4.6 type update. [Too much software does this from Oracle, Microsoft to joes-open-source-email-reader] That is the nature of a lot of software which will bite you over and over again if you don't put in processes to mitigate that. -- Stephen J Smoogen.