>
major.minor.date format looks like a compromise that have the best of both worlds
Agreed ….. I actually also liked the additional proposal earlier of
Major.minor.SIG.date
Where Major.Minor is the contents of redhat-release from which the CentOS version is built
SIG is core, cloud, …
Date is the source code extraction date (I guess this is more relevant than the build date)
SIGs potentially have a more complex case where they’ve got a particular code drop from Core and have then applied a particular source code tree from the SIG. An example would be where the cloud SIG starts work on 7.0.core.20140710 tree
to include the latest software defined network drivers and this is finally available on 20140725 after some work. The date to present, in my view, is the SIG date (i.e. 20140725) but it is not clear how to distinguish the core release from which it is derived.
Tim
From: centos-devel-bounces@centos.org [mailto:centos-devel-bounces@centos.org]
On Behalf Of Roger Pena Escobio
Sent: 21 June 2014 15:35
To: centos-devel@centos.org
Subject: Re: [CentOS-devel] CentOS 7 and release numbering
|
Once again But, I still see a big plus by having a release like mayor.minor.date, it is more flexible without breaking the old way , both side wins because a client could see/notice that their 7.0.x is too old when it was getting refreshed every now and then (asuming
there will be respins more oftens that rh releases) Ok, let me go further in a mental exercise, let say we make the change proposed and the .minor number is changed to .date of release. Lets imaging a year from that release there is serious vulnerability that put the world to check "am I vulnerable?". Manager
or lazy SA check that we are running 7.20140701, they are not familiar with, they might even remember that was created when rhel7.0 was released but to be sure they go to a wiki and confirm that indeed that release of centos is the rebuild of rhel7.0 but they
probably also notice that there are newer resping of centos based on newer releases of rhel, and probably they might notice that what they are running is no supported anymore raising more questions to them. What this might have different if we keep things
as they are right now ? Probably because of what you are saying , that hypotetical person might hope/expect/ that centos is also following what redhat is doing and a fix will come in there way but at that point updates will not work unless conciously a manual
change was performed and a the only update available might be a new centos release saying it is not supported Make sense ? Thank Sent from Yahoo! Mail on Android |
From:
Johnny Hughes <johnny@centos.org>;
To: <centos-devel@centos.org>;
Subject: Re: [CentOS-devel] CentOS 7 and release numbering
Sent: Sat, Jun 21, 2014 10:42:26 AM
|
On 06/21/2014 05:00 AM, Ron Yorston wrote:
|