[CentOS-devel] CentOS 7 and release numbering

Sat Jun 21 16:56:48 UTC 2014

On 06/21/2014 08:49 AM, Ljubomir Ljubojevic wrote:
> On 06/21/2014 03:47 PM, Ljubomir Ljubojevic wrote:
>> On 06/21/2014 03:31 PM, Roger Pena Escobio wrote:
>>> Once again
>>> If the goal is to point to the fact centos 6.4 is different than rhel6.4
>>> after 6.5 is out, then make something right when the differentiation
>>> start and not before
>>> You can release a new centos release package for 6.4 or you can do
>>> something on the repo, that make it clear to client, that something
>>> changed and updates do not work anymore unless the SA does some concious
>>> local change to make it not complain again, will that break some auto
>>> update on those clientes? Yes, but that would be desired to make it
>>> clear that something is requiered from the local SA in order to keep the
>>> box secure
>>>
>>> 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 ?
>>> Again, having major.minor.date format looks like a compromise that have
>>> the best of both worlds
>>>
>>> Thank
>>> roger
>>>
>>> Sent from Yahoo! Mail on Android
>>>
>>>
>>> ------------------------------------------------------------------------
>>> *From: * Johnny Hughes <johnny at centos.org>;
>>> *To: * <centos-devel at 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:
>>>
>>>   > Johnny Hughes wrote:
>>>   >> What better way to communicate that they are not standalone but are all
>>>   >> only part of the MAJOR release and a POINT IN TIME part of that major
>>>   >> release than to name them "<MAJOR RELEASE>.<POINT IN TIME>" ?
>>>   > The current scheme represents <POINT IN TIME> as an integer that starts
>>>   > from zero and increments with each minor release.
>>>   >
>>>   > I remain unconvinced that a YYMM representation of <POINT IN TIME> is
>>>   > any better.
>>>
>>>
>>> It is not really better at conveying time, no.  It is the same at
>>> conveying the time.
>>>
>>> Where it is better is in denoting that Red Hat is doing things inside
>>> the 6.4 tree (again, just following the above example) while CentOS does
>>> not do those things inside our 6.4 tree after we release 6.5.  We can't
>>> do them, even if we want to as we don't have the sources.
>>>
>>> That is my whole point .. we need a way to convey a similarity and one
>>> point, while not being similar always.  Having the exact same name does
>>> not convey that.
>>>
>>> How do you suggest we do that and not ignore that there are potential
>>> differences after we move to the next point release?  Do we just ignore
>>> that part?
>>>
>>> Everything on this list that is newer than 2013-11-20 is in the RHEL 6.4
>>> tree ... we don't and can't release any of it for our 6.4:
>>>
>>> https://rhn.redhat.com/errata/rhel-server-6.4.aus-errata.html
>>>
>>> So our 6.4 tree is now significantly divergent from the Red Hat 6.4
>>> tree, and our 6.4 tree is in the vault and not live anymore ... don't we
>>> have an obligation to our users to make sure they understand that there
>>> are differences?
>>>
>>> UserA has some software that only works with 6.4 .. he sees CentOS-6.4
>>> in the vault and grabs that to use with his software.  He can't upgrade
>>> to 6.5 because it will break his software.  Staying on our 6.4 tree will
>>> leave UserA vulnerable with security issues.  If he is instead on the
>>> Red Hat 6.4 tree, he is still going to be able to get updates.  Do we
>>> not have any obligation to change our numbering so that UserA can more
>>> easily tell this hugely major difference?
>>>
>>> We don't really have the upstream point releases, we have different
>>> point releases.  We release the main line CentOS-5, CentOS-6, and
>>> CentOS-7 ... we do point in time respins of ISOs and install trees,  Red
>>> Hat does all this and a bunch more things also inside point releases.
>>> These two things are not EXACTLY the same ever, but they are very
>>> similar for one 6 to 8 month "period of time" (while they are OUR active
>>> release and Red Hat's active release) and they become increasing
>>> divergent after that point in time.  That is what I am trying to convey
>>> here.  Some people will argue that people have to pay for that other REd
>>> Hat 6.4 tree ... sure they do.  They also have to pay the initial Red
>>> Hat 6.4 tree, they have to pay for everything there, thats how it works.
>>>
>>> Everyone here thinks that we should just leave the point releases as is,
>>> knowing that now Red Hat is doing completely different things inside
>>> point releases and that we don't have an obligation to point out the
>>> differences?
>>>
>>>
>> I "yum update" moves you to newer version, then it is all the SAME as
>> today. Updating WILL update that system beyond support.
>>
>> If we need to reproduce point-in-time releases, then lets create base +
>> updates repositories for every minor release (6.4 for example) and
>> update it with only security fixes.
>>
>> If we do not want to change the way CentOS is updated, then all we are
>> saying to people is "We do not WANT to be same as RHEL, so if you want
>> RHEL then buy it" which will brake a trust people have in CentOS binary
>> compatibility with RHEL.
>>
>>
>>
> Just to emphasize, people want COMPATIBILITY with RHEL, that is why we 
> use it. If there will be no PERCEIVED compatibility, people will start 
> waling away from CentOS. As simple as that.

And the CentOS goal is full functional compatibility.

We do now have and will continue to have that.

Changing a number in the name does not impact that at all ... it just
means we are trying to better describe what CentOS is.

-------------- 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/20140621/392f5834/attachment.sig>