Version Numbering Vis A Vis CentOS And RHEL

Home » CentOS » Version Numbering Vis A Vis CentOS And RHEL
CentOS 15 Comments

OK, I’m staring a new thread.

To you, and probably a majority of CentOS users, the “version number” of CentOS is indeed a trivial, cosmetic issue.

However, there are those of us who use CentOS in a very large enterprise environment. That is, in fact, the intended audience of the whole distro. When there is a “new version” of Red Hat (and I know that means nothing with hundreds of constantly updating packages; however, my bosses don’t get that), and hence CentOS, there is a huge amount of work that needs to be done in a typical enterprise. These include, but are not limited to:

– setting up a new internal-only mirror of the distribution
– setting up a new TFTP/PXEboot/kickstart environment for network installs.
– Editing several install scripts to match the new environment
– Testing all these changes
– Checking that all security recommendations/edicts from a higher authority
(e.g. the US Government), which are also based on the “version”, are followed
– Checking that all commercial software supports the release (most of these use “RHEL X.y”, what is that in CentOS now?)
– Trying to get support from commercial software when the “version numbers”
don’t match
– Coordination of other repositories (e.g. EPEL) is based on the “version”, how does that work now?

All of these things ran in parallel with the RHEL release cycle, and the work could be done at the same time. That was the overriding philosophy of CentOS, “we are a recompile of RHEL.” Now, the impression is (rightly or wrongly, it doesn’t matter to me) CentOS is totally becoming a separate Linux distro, and needs to be treated as such. And that has huge implications for system administrators in a large environment. Huge.

There are answers to all these questions, but there is a lot of confusion that’s been generated by this seemingly cosmetic change in version numbers. I’ve checked, and there was no,”We’re considering creating this basic difference from RHEL, how will this affect you?” on this list, or the website, etc. From our viewpoint, it was sprung on us out of nowhere, and now were being told “deal with it, or leave.”

It sucks.

15 thoughts on - Version Numbering Vis A Vis CentOS And RHEL

  • Exactly the same as it did before. Before you’d have a $maj.$min repo, which is the same as it is now. maj=7 min=1.1503

    You can park it there and not suffer any problems as I understand it. At least that’s what I’ve done with 7. So when 7.2 finally hits, it’ll be maj=7
    min=2.1512

    I don’t see it as an issue. A partially updated (without touching CR) 7.1.X
    is equivalent to a partially update 7.1 RHEL.

    To me, I’m not sure I get any issues or advantages from the new scheme, but I
    can’t say it bothers me greatly.

    jh

  • This is the thing that bothers me most – that folks dont have a good grasp on what / why the numbering is working like this.

    We are still a small team, and all efforts are flat out on getting the iso media and images done, out of the door – but as soon as I have this done, I’ll look at hosting some google hangouts, irc sessions and maybe a longer email thread as well to lay out the numbering proposition.

  • IRC is not a good choice for communicating with IT admins in a large enterprise environment. It is usually blocked.

  • 1. Thank you, Matthew, for a new thread. This had nothing to do with the o/p
    of the old thread.
    2. I’m not sure what more can possibly be said that hasn’t already. Can we
    end this, unless the Board decides to solicit our opinion, and
    get back to solving issues?
    3. Board of CentOS: some folks don’t care about the numbering, but it bothers
    a *lot* of us, and at least to me, that doesn’t seem like a huge deal
    to change; it’s not something critical to the distro. Therefore, I’m
    politely asking you to revisit the issue in your meetings, and
    reconsider the x.y.# (e.g., 7.1.1511).

    mark, still struggling with bareos and windows

  • In my case, yes, Hangouts works.

    However, in general, any time dependent method is a problem since there’s probably some fire to be put out at any given hour.

    I, and I suspect others, would prefer asynchronous communications so we can contribute when we have time.

  • Hi Matthew,

    your concerns caught my attention. We are maintaining a good amount of Linux servers, both RHEL and CentOS, and always used our own numbering scheme in form of major.minor.patchset, where the patchset is a sequential number telling how many times we generated the patchset, like
    5.11.5, 6.7.2 and so on.

    AFAIK, the 7(1503) format is used only on the websites, and internally CentOS uses 7.1.1503. Do you see this as an issue? In that case, simply ignore the build number in your scripts and use major.minor only as before.

    Just my 2 cents…

    Best regards Zdenek Sedlak Infrastructure Architect

  • Yes. It confuses humans. There have been a bunch of examples given of how it confuses humans. A simple fix for this human issue is to use
    7.1.1503 on the website, here on the mailing list, etc.

    — greg

  • And then we’re right back in the same old boat: With every new release, the same old thread will pop up, “How do I make my servers stay on CentOS 7.1?”

    Give up on the point release idea. It’s CentOS 7; there is no CentOS 7.1. The only reason there’s a YYMM part is that it’s a media respin. Best ignore that wherever practical.

  • So if we are to give up on the point release does that mean I don’t have to update my machines until CentOS 8 comes along? ;-)

    Seriously though, since I have to build my own repos (air gap) and build the images for the diskless machines the point releases are important in tracking roughly which version particular nodes are on. Running yum update on a regular basis is just not an option.
    —–BEGIN PGP SIGNATURE—–
    Version: GnuPG v2.0.22 (GNU/Linux)

    iQIcBAEBAgAGBQJWZhltAAoJEAF3yXsqtyBlyAoP/2/kIa8gzhiNKoCRPFbFW/AT
    2B15B/BDdBhIYN66Ux58cScMwfBt5Z9McozvWp2yJurr5CSrxG4wywXS6sfyRrYw
    7J4oplTc5lmaxZkyQIidYVJ0Rwf9h0gCPx2TW7aoPcjh9YcqtjS4zZP1AHRuMY56
    Wkt2RfuAaq3LUlRD4TwPNA3UMgvR18N3L9H7p2hXxYvswmKzWzTNt0M1AD8BeLBf S9cUSKGgAHikexjm6gmKQ2Nxb6xGcQE4lgPRCP/57cM5hX3rvhvTH4URj1+VUGw0
    hd135wVk//AeK+lHXbm3ejNV/UC/sRx/JAOsaC2FYsBvfggsCuc0CUUxaGAOLZtt cfDLJgqKQdy59XAuWjRzw3Z4m+IPqSxeBopPDTwzUOiZQYxxOq2LZO2XQHzxbO+d VMqarwOp3n4nZvBDUeq+Q80LrrZtMGRlPtVA/YFHazVJPZ9Xo5ugV9QrdZrPO4kE
    LzrwjWevRT64g1mOInSSyWrOqFbXXMrZbAeJ88csUSTAaGwVDU3vZ3tAMuar8IKa k2IJBDBBDYQB5XZEkny5wTecS+/0B2M2ylEVyWe6GvvS5er+O6iop0Ej74O4OwGy FA7OwV7pzmWxnyzn4L/YUxAYSsSVL5rTdEAUGpFcetDd4oQssyV0Z9OtWKNeJIkx P+ZlCDMcxY08ajJenqm8
    =SSct
    —–END PGP SIGNATURE—–

  • I’m missing the connection. That’s the kind of thing that’s a FAQ. If you look back in this list archive, you’ll see me answering that question here, and pointing out that the answer is buried in the FAQ
    on the website. (Never fixed despite many comments, but hey, why fix things that are problems?)

    I don’t see why putting the same thing in /etc/CentOS-release and the website causes this problem to be significantly worse.

    I do see how the current “7 (1503)” on the website confuses many humans, including experienced CentOS admins.

  • You should be updating during the lifecycle to each milestone though… To not do so is to leave yourself open to numerous bugs and attacks.

    As it is, as pointed out, you can still check the installed files from the CentOS-release package for the upstream it’s based on and the YYMM respin date…

    Common configuration management systems (you should be using one of these given you say you have many systems) will also report the relevant details correctly.

    On top of this if you are maintaining your own internal air gapped repo you should be paying attention to announcements which will inform you at these milestone points…

    Given the workflow you state nothing has changed for you with the EL7.X
    releases…

  • What I want to know is, why is CentOS doing things differently than RedHat?
    Who made this decision, and was there any consideration given to making such a highly visible departure? When did CentOS decide to fork away from RHEL? It doesn’t matter if this is truly the case, or not. Perception is reality here; CentOS is now no longer “the same” as RHEL and this turns it into a whole different, new, distro of Linux. That affects things like software certification, hardware support, security certification, etc. etc. It is now a stupendous burden on those of us who chose to implement it because it was “the same” as RHEL.

    Was this an edict resulting from the RedHat acquisition of CentOS?

    I can hear people saying, “Well, why don’t you just use RedHat then?” I
    probably will have to now. But, we chose CentOS because it *was* RHEL, but it gave us more control (the ease of air-gapped repositories is a good example).

    I just think this whole thing was a highly unnecessary, and bad idea. And it has a lot of really serious repercussions that nobody seems to have thought of before plowing ahead.

    And, obviously, that angers me. I am asking for more than just consistency between the web site and /etc/CentOS-release, I am asking that, starting with RHEL 7.3, that CentOS stop using YYMM in its version numbers completely.

    —
    Matt Phelps System Administrator, Computation Facility Harvard – Smithsonian Center for Astrophysics mphelps@cfa.harvard.edu, http://www.cfa.harvard.edu

  • on the flip side, ignore the point in time, assume you run /7/ and need to update as you go along, with the YYmm telling you how far adrift you are… in workloads where there is no real update in place ( think cloud, container, atomic etc ), its the only reference you get to a single package set.

  • CentOS has always been different than Red Hat Enterprise Linux, because Red Hat is willing to support older point releases of RHEL
    (for a price), while CentOS only supports the latest release. You might be running RHEL 7.1 Extended Update Support for another year or so, while the rest of the world has updated to RHEL 7.2.
    (see https://access.redhat.com/support/policy/updates/errata)

    I believe (although I was not involved with the choice) the new naming scheme reflects a need to advertise to the end user that there is only one supported release of each major version of CentOS, with a regular release of installation medium that coincides with the feature updates that come out with each RHEL point release.

    So often, I see people come on mailing lists and the IRC channels saying “I’m running CentOS 6.1 and I can’t get PHP to work” and we have to ask why they aren’t running a supported release of CentOS 6. A lot of people seem genuinely surprised that you can’t just keep running some point release of CentOS and expect any kind of support.

    I’ll admit, the use of 7.2.1511 is *helpful* because then I know what upstream version of RHEL it is based on, however, I’m also using RHEL7
    along side CentOS7. But in terms of naming the install medium, it makes sense to just put a monotonically increasing number that reflects a timestamp.

    This is just my opinion, as both someone who tries to be helpful to CentOS users, as well as a sysadmin in a large institution.