[CentOS-devel] CentOS 7 and release numbering

[Johnny Hughes]

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.sig>