[CentOS-devel] CentOS 7 and release numbering

Tue Jun 10 12:19:37 UTC 2014

Karanbir,

So far, the community input seems to be strongly in favour of keeping the x.y conventions (potentially adding a timestamp for areas such as cloud images).

Among our user community, a change to timestamp only would cause significant confusion. We do not have the opportunity to explain at length that YYMM is compatible with y and that there is a web page giving the mapping between versions.

I am not yet seeing major enough benefits to make such a change, especially at this point of transition of the community in view of the downstream difficulties it will cause for those of us supporting large user bases where these conventions are well established.

Tim

> -----Original Message-----
> From: centos-devel-bounces at centos.org [mailto:centos-devel-
> bounces at centos.org] On Behalf Of Karanbir Singh
> Sent: 10 June 2014 13:09
> To: centos-devel at centos.org
> Subject: Re: [CentOS-devel] CentOS 7 and release numbering
> 
> 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
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> http://lists.centos.org/mailman/listinfo/centos-devel