On 06/07/2014 05:56 AM, Tim Bell wrote: > > A few quick thoughts.... > > 1. Does the SIG need a naming convention also, e.g. > > CentOS-7.1407-Cloud-140805 > > i.e. the cloud SIG based build done on 5th August 2014 based off the CentOS 7 tree in July 2014. > That is what we are looking for, a 3rd component for the SIGs, so that they can (if they need to), delineate something that is different on the end. It allows for mix and match as the SIGs see fit. > 2. The minor release number is not in the naming convention. Is this a question of length ? > > CentOS-7.0-1407 > > I am thinking as we get to beta releases of 7.1, having a mechanism to name the beta releases independently of the production ones would be useful. > The issue with 7.0, 7.1 or 7.2 versus 7.YYMM is this (I'll use 6.4 and 6.5 and real dates/times in my example): CentOS has never supported older versions than the current release. Red Hat, by default behaves the same way. As an example .. if you install CentOS-6.0 or RHEL-6.0 then at install time the ISOs contain similar versions (ie, the mysql versions and firefox versions offered at the same, etc.) If you did this install during the 6.4 time frame, then did an update, you would get the updates from the 6.4/os tree and the 6.4/updates tree. This works the same way for both CentOS and the Default RHEL installs. The problem that happens is that Red Hat also offers some subscription services called AUS, EUS, and ELS. ELS is Extended Lifetime Support which is something you can purchase after a products End Of Life is reached (you would need this to get any support or updates for RHEL-4 now). AUS seems to be longer life support for the "minor" branch (the .4 branch in 6.4), so in this subscription you would continue to get security updates for RHEL-6.4 even though RHEL-6.5 is released). Then there is EUS which seems to add a Z stream for 6.4 ... so a 6.4.1 and 6.4.2. I have no idea what its relationship is to 6.4 AUS ... that is beyond the scope of this mail and the CentOS project. (If you want to understand the nuances of RHEL subscriptions and the extended lifetime offerings in detail, contact the Red Hat sales team and they will gladly explain it in all its detail :) ) While we are not experts on what all of these Red Hat extended lifetime product acronyms mean and provide, they do all relate to the CentOS Linux distribution in exactly the same way. Red Hat does not now, nor have they ever provided those sources to the public, but only to the specific customers who are in those specific subscriptions. So, CentOS has never, and will never release these kinds of updates (unless Red Hat changes they way they release that source code). Now to the problem. A CentOS minor version relates to a point in time snapshot of the all packages at a specific point in the lifetime of the major version. So that means that all 6.4 designates in the CentOS-6 distribution is that the "os/" directory of 6.4 matches the packages on the installable media that we produced on the date we built it and that it also matches the versions of software that is at that some point in time on Red Hat 6.4 ISOs. So, at the specific point in time, the distros are similar from a versioning perspective. All the non extended lifetime releases will go into our 6.4 updates directory and 6.4/os with 6.4/updates will have package versioning that is the same as the versions that are represented on this page for a given date range: https://rhn.redhat.com/errata/rhel-server-6-errata.html (Note: this is using the RHEL "Server" (v. 6) General Advisories .. we track everything in all the other "v .6" branches as well (Workstation, Desktop, HPC Node, Resilient Storage, High Availability, Load Balancer ... and FasTrack for each that have them) But for explanation, lets just use the server page linked above. If you look at that linked page, Red Hat did a release of 6.4 on 2013-02-20 and they did a release of 6.5 on 2013-11-20. Our CentOS-6.4 release includes all versions of software on that page (our rebuilt software of course, not Red Hat software) that RH included on their ISOs up to the release point. Throughout the lifetime of our CentOS-6.4, all the updates that happened between those two dates went into our 6.4/updates directory. During the lifetime of 6.4, when it is on our main servers, if you yum update our product or RHEL if you would get similar versioning of your saftware packaging, etc. But when RHEL-6.5 happens, we start a new CentOS-6.5 tree. This is where there is confusion and what we are really trying to address ... Red Hat still has 6.4 AUS and 6.4.z EUS updates that they do ... and you can look at them here: AUS: https://rhn.redhat.com/errata/rhel-server-6.4.aus-errata.html EUS: https://rhn.redhat.com/errata/rhel-server-6.4-errata.html I know this is complicated ... but its important, so bear with me :) So CentOS-6.4 stopped being supported when we released CentOS-6.5 ... we moved 6.4 to our vault. All the updates in the 6.4 channel stopped at that point and we started doing the new updaes into 6.5 .. our 6.5 "os/" is what is installable on the ISOs and our 6.5 updates (anything after 2013-11-20) is in the 6.5 "updates/" directory. But Red Hat still has not only their "v. 6" channel (which the CentOS versions are based on and are always up2date), but they also have those other two 6.4 channels (AUS an EUS). Lets look at a security update ... the important OpenSSL one from 2014-06-05 ... if you look on the "rhel-server-6" above, it says this is the update that fixes the issue: https://rhn.redhat.com/errata/RHSA-2014-0625.html That is version "openssl-1.0.1e-16.el6_5.14.src.rpm" ... Red Hat released that publicly, CentOS grabbed it, built it and put it in our 6.5 tree in the updates directory. If you are on our 6/ or 6.5/ tree, you got the update and all is well. If you are instead running CentOS-6.4 .. all is not well. You will never get that update. But, Red Hat has those other subscriptions ... AUS and EUS .. and those have this for 6.4: https://rhn.redhat.com/errata/RHSA-2014-0627.html On that page, there are these available for 6.4: AUS: openssl-1.0.0-27.el6_4.4.src.rpm EUS: openssl-1.0.0-27.el6_4.4.src.rpm (in this case the same package) But, Red Hat only gives out that package and its sources to customers that are in one of those "extended" subscription plans ... so therefore CentOS does not build that and we do not update our 6.4 directory on vault for this problem. So, one major thing that the CentOS Project is trying to convey with this version number change recommendation is that CentOS is really Version 6 ... NOT version 6.4 and 6.5 ... and that we have snapshots in time of our tree to add newer hardware and software to the installer. But the only supported version of CentOS-6 is ever "the latest". We have said this many times, its in FAQs, on the mailing lists, etc. Regardless, people still think they can get security updates out of band (ie, 6.5 updates with 6.4 installed). We think that making the "Point In Time" (in this case, Date in the form of YYMM, since we will never have 2 releases in the same month) be the minor release number, instead of the RHEL minor version number, helps convey this concept and much better serves our users. In my above example, if we were using the newly proposed numbering system, Red Hat would have 6.5, 6.4, 6.5 AUS, 6.5.z EUS, 6.4 AUS, 6.4.z EUS. There could be as many as 5 packages that would address the fix. CentOS on the other hand would have two releases ... 6.1302 and 6.1311 ... if your release is older than a year (normally even older than 9 months) then it is easy to tell (Feb 2013 is too old .. am I on the supported release). You can easily see that you are running a non supported tree. Also, 6.1311 would be the 5th listed version released, so if you were looking at a list, it would be number 5 on the list .. also traceable that way. But with the other Red Hat 6.4 offerings, we think that only causes confusion for CentOS users and we don't want that. We think this system conveys exactly what we want to project with our versioning system. For CentOS-6 the releases would have been: 0. CentOS-6.1011 1. CentOS-6.1105 2. CentOS-6.1112 3. CentOS-6.1206 4. CentOS-6.1302 5. CentOS-6.1311 As you can see, the minor numbers also match in the list (6.3 matches 6.1206) ... it's very easy to see that there are 6, 7, 7, 8, and 9 months between releases, etc. Thoughts? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140607/f9866d61/attachment-0007.sig>