[CentOS-devel] CentOS 7 and release numbering

Tue Jun 10 11:09:23 UTC 2014

On 06/09/2014 07:41 PM, Ned Slider wrote:
> "Finally, a versioning scheme such as this would allow us to version and 
> track builds that have in the past struggled in the x.y regime (eg. 
> cloud images, updated at point in time against security vulns or to 
> incorporate vendor environment changes)."
> 
> Finally I see the first hint of a technical issue that might actually 
> require a solution, but I still don't see it needing such a perceptually 
> important change as to altering the release numbering.

There are a couple of things here worth bringing up

1) the focus on the distro has always been on the major release ver, we
always communicate ( or try to ) that the person is running CentOS-5 or
CentOS-6, and not so much 6.4 or 6.5; these are point in time labells.
So they should be considered that.

2) A clear example of what the datestamp tries to workaround is
yesterdays docker updates ( and the AMI and GCE images etc ) that were
done to CVE fix openssl content. These are not marked as a point at all,
just a centos-6-x86_64-20140609 ( and in most cases, the link that
people hit is for centos-6-x86_64, which points at the latest images );
this is becoming more of an issue as the cloud side of things grows,
even within CentOS we've seen a massive increase in uptake on that side
and I am sure everyone sees that.

3) the CentOS Linux distro is going to do no more or no less releases
than RHEL is. There seems to be a bit of miscommunication here that
having a datestamp will allow us to do monthly builds, sure - but we
wont. The main distro is going to be an exact 1:1 rebuild of RHEL, as
we've done in the past, to be no worse than we were before - hopefully
improving as we move forward as a larger group.

4) Communicating a relationship between the point release in 7 at RHEL
and CentOS isnt something that goes away either. There have been some
great suggestions on this list already as to what we could do to retain
that message. eg: Maybe CentOS Linux 7.1406 ( 7.0 ), sort of a scheme,
and for those who prefer names, maybe we do the Alpha, bravo, charlie or
something like that. In either case, the A, B, C will map exactly to 0,
1, 2 - with no interim release going into the main distro.

4.1) Another interesting idea is to have /etc/redhat-release contain the
upstream versions, while /etc/system-release points to
/etc/centos-release that can have a centos specific release string (
that itself can still contain upstream references )

4.2) Anaconda will, ofcourse, still need to retain the same version
strings are upstream, otherwise driver disks from third parties are not
going to work.

4.3) yum still consumes release data, again - pointing to /ReleaseVer/
only, and that will be un-affected. People tweaking it to local flavour
can still do so.

4.4) lsb_release info can still ( and really -must- ) report the
upstream versions, so manifests written on CentOS can still work on RHEL
and vice versa.

5) SIG's and variants can and will do their own releases, based on their
own roadmaps, using CentOS Linux as the baseline platform and they can
chose to do as much or as little code share with the platform ( but
ideally, there will be some value to it, which is why they are here in
the first place ). They can then chose to do releases that branch from
CentOS, but they cant call it CentOS Linux. eg. if the storage SIG

The problem definition is mostly down to :
- finding and focusing on the ReleaseVer rather than the point releases,
but still retaining the ability to map the iso builds so external
drivers, kickstarts, hardware upgrades etc an be identified and managed
in sync with what happens in RHEL.

- Making sure that the cloud and instance images have some level of
relationship with the mainline distro, this is an increasing issue we
need to handle.

- Try and provide the SIG's with a way to do something similar, diverge,
rename their delivered content ( eg. CentOS Ceph Server ), and yet
retain relationship with the mainline distro

- RHEL point releases that contain different content are no longer
confused for CentOS point releases. A problem recently highlighted with
the openssl heartbleed issue where every Scientific Linux 6 install was
impacted, whereas only a part of the userbase on CentOS 6 was, and a
different set of people on RHEL 6 were. One could argue that everyone
who had done updates on CentOS was impacted, and that is true - the
situation becomes grey when you consider people who were on point
releases and were updating against different release tree in SL, CentOS
and RHEL.

- This will make it easier for people to maintain site-local content and
golden images that they can curate on their own, policy and deliver
around it on their own, without needing a new versioning schema. Lots of
hosting companies and voip providers do this, and everyone has their own
process's and policies, which are always going to exist - but they all
also have their own versioning, which always leads to confusion.
Interestingly, almost all of them include a datestamp in their golden mark.

In summary : there are various things that line up, and there are many
potential wins that we can draw from here, without changing the user
experience or impacting technical legacy. If we are, then we need to
find a way to not, or find a way to work around it.

Also, CentOS-7 is going to be coming up soon - we have the buildlogs
already going to a list, and now also on http://buildlogs.centos.org/ -
not putting rpms there as yet, since we dont want that machine ( and
vitelity.net who gracious donated the machine ) to complain. We are
going to try and get a few more machines behind it, and the buildsystem
output becomes visible right away, in near real time. Highly encourage
people to QA / QE in sync with the builds ( bootstrap from the 7rc isos
). Fairly sure we can iron out issues ( and come up with a better naming
if it were so ) that still resolves the issues at large, helps us build
the centos image, and yet no technical legacy wreackage.

lets not forget, we've been ahead of RHEL delviering better value at
many places. we had the X.y regime before they did, and i wont be
surprised if they struggle to maintain messaging around the relevance of
a X.y into the future ( but thats a different problem :D )

-- 
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc