[CentOS-devel] CentOS 7 and release numbering

[Ljubomir Ljubojevic]

On 06/20/2014 06:56 PM, Stephen John Smoogen wrote:
>
>
>
> On 20 June 2014 10:43, Tim Bell <Tim.Bell at cern.ch
> <mailto:Tim.Bell at cern.ch>> wrote:
>
>      >
>      > So, for all periods outside the active time that a tree is live,
>     the CentOS 6.4 tree
>      > is radically different than the RHEL 6.4 tree.  That is the issue
>     I want to address.
>      > CentOS 6.4 does not equal RHEL 6.4 ... and it is especially tree
>     after the 6.5
>      > release.  I think that there is obviously an issue in perception
>     that people think
>      > they can stay on an old tree and get the same thing they would in
>     RHEL,, and
>      > they can't.
>      > They can't on CentOS ... they can't on Scientific Linux, they
>     can't on any of the
>      > rebuilds.
>      >
>
>      >From my understanding, RHEL by default gives the same (i.e. you
>     follow the tip) unless you turn off yum. It is only if you pay extra
>     for EUS do you get the branch updates.
>
>      >From what I can see,
>
>     - There is interest in clearly marking the release with a date to
>     show from which source it is taken when the base code was built.
>
>     - There is interest in maintaining some correspondence. As you
>     mention, it is currently like that for Scientific Linux CERN and we
>     have not encountered confusion with our community.
>
>     How about we take the following approach
>
>     - We define the point release as being the one that Red Hat define
>     as their point release in the code from which the build is derived
>     (i.e. the contents of redhat-release in the git repo). This is the
>     closest indication of the correspondence with RHEL.
>
>     - We define a date based extension which indicates the date that the
>     build was done.
>
>     This would produce a version number along the lines of 7.0.1406
>     which would not be confusing to those who have been using the
>     distros previously and indicate the time based nature of the work.
>
>
>
> To extend this a bit further I was going to say
>
> 7.0.core.201406 # Rather not be Y2100k compliant :)
> 7.0.storage.201407
> 7.0.openstack.201408
>
> that way it covers everything:
>
> Upstream release: 7
> Upstream starting point branch: 0
> Downstream SIG: core, storage, openstack, desktop, etc etc
> Downstream Release Date: 201406, 201407 etc
>
> The files that need to be parsed by tools by vendor tools (eg Oracle
> wanting 6.5 and not running on 6.4) can have the two parts that are
> needed. The parts that community support members need (which SIG was
> this and which releasedate in case of say openstack doing weekly
> snapshots.. ) are there.
>
> And no I am not a stickler on 201406 versus 1406 .... just like my ISO8601
>
> --
> Stephen J Smoogen.
>

This could be workable. Ditching minor version would be harmful and 
would create havoc with newbies. And people doing CentOS support would 
go out of their minds explaining the difference.

I personally would HATE to promote CentOS by consulting release 
timetable so I can relate RHEL to CentOS versions. I would most likely 
just give up giving support and mind my own business. There is a line 
over which I would not be ready to give back to the community anyway I 
can. Havoc of "So what version of CentOS is for RHEL 7.3?" is definitely 
that line.


Johhny, I still do not understand what you are trying to do. And I fall 
under top 1% of population by Mensa IQ test. Imagine person with IQ 120 
with poor English skills. Imagine all those CEO/IT Head's and Managers 
perception of the Linux world. Imagine what all those others will 
think/reason it ALL of the highly tech people in dev list are screaming 
"bloody murder"!?

Huge number of people will still use CentOS 7.x for Desktop/Laptop or 
standalone Servers. No docker, not even KVM. Just plain bare metal 
distro. And with CentOS/RHEL visual improvements and reaching technology 
level good for Desktop/Laptop use (Steam for Linux, Chrome/Chromium, 
modern kernel) things are actually looking up. Kernel with Real-time 
Audio support could make CentOS stable media distro, for "install and 
forget" systems.

And you would kill all that by alienating all those people with worst PR 
nightmare you could ever create. 90% of Linux users will just say RHEL 
!= CentOS anymore, no matter what you would say. And everything would 
start loosing traction. On the eve of new era for CentOS.


Lets get back to me not understanding your reasoning.

I and 90% of other admins who install and administer our own systems 
will install 6.4 and do "yum update" and we will be on 6.5 Right? So for 
them we should have "please keep this system properly updated with 'yum 
update' to be safe" warning where ever we can, logins, mail to admin 
mail account, in logs. Either you keep minor version or have timestamp, 
they will do what they want.

That leaves those images expert admins are going to work with.
So, you create docker image with 6.4. And you want what? To update to 
correspond to only 6.4 EUS (whatever) updated packages? Why not just 
create another repo for 6.4 EUS updates so that image uses 6.4 os/base 
repo + updates-6.4/updates-64 repo? SiG would manage that repo and 
everyone would be happy.


If you do not want to keep that docker image on 6.5 then "yum update" 
will bring it to latest, and again everything is solved.

So basically, If I understand you correctly, you want to solve lack of 
repository for updates against 6.4 version with PR disaster. Right?


-- 
Ljubomir Ljubojevic
(Love is in the Air)
PL Computers
Serbia, Europe

StarOS, Mikrotik and CentOS/RHEL/Linux consultant