Today, in CentOS 5 and 6, when I issue a yum update, lets say, on CentOS 5.5, it will bring me to the latest CentOS 5 version, 5.10 for example.
This same behavior will work in CentOS 7? Or I have to change my repos settings?
I didnt know about the RedHat versioning system either and I understand the need to adapt the CentOS versioning too.
I think we all want to be able to tell our customer / users that they must update do CentOS 7.1 to fix some security issue instead of checking if they are on 7.20140619 and must update to 2.20150704. Although, it is possible to release and security patch for verion 7.0 without releasing a veriaon 7.1 and that would be done on a 7.xxxxxx branch?
[]s.
----- Original Message -----
From: "Nathanael D. Noblet" <nathanael at gnat.ca>
To: centos-devel at centos.org
Sent: Friday, June 20, 2014 4:52:09 PM
Subject: Re: [CentOS-devel] CentOS 7 and release numbering
On Fri, 2014-06-20 at 10:38 -0500, Johnny Hughes wrote:either
> On 06/20/2014 08:52 AM, Alessandro Ren wrote:
> > Johnny,
> >
> > I dont think anyone lacks confidence in your work or in CentOS and everybody appreciate the time you've dedicated to the project.
> > I my self have not yet clearly understood the real idea behind the new versioning system and I really dont know why the classic model would not work.
> > I think the main success of the project is being closely related to RHE.
> > My main concern is the risk of not keeping with the last security updates or not seeing them as clearly due to the new versioning.
> >
> > []s.
>
> I said at the beginning of this topic, but I will say it again here as
> clearly as I can ...
>
> Red Hat has a tree ... we can pick any one, I'll use 6.4 as an example.
>
> When Red Hat releases 6.4 they release an ISO set and a tree. Red Hat
> splits their tree up into several versions, for which they can charge
> varying amounts of money (Server, Workstation, HPC Node, Client, etc).
> CentOS has no need for these designations and we flatten it out into one
> main repo .. since everything is free in CentOS. We have groups that
> mimic the functionality of those segments.either
>
> So, at the time of release, other than the things we purposely do not
> build (install numbers for the ISOs, RHN subscription items) the version
> numbers match up almost exactly as we use the source from RHEL to make
> CentOS.
>
> The differences between the Red Hat and CentOS trees start to happen
> AFTER the next release.
>
> When 6.5 comes out, we again use the RHEL source code and do our thing
> ... and we take the 6.4 tree out of production and put it in our vault.
> This is because Red Hat does not publicly release changes for that tree
> anymore. However, behind the scenes, Red Hat does do changes to that
> tree for their paying customers. The release updates for that 6.4 tree
> for up to 3 years. This is something they have always done and
> something CentOS has never been able to do. Those things are going to
> continue in the future as well, Red Hat makes the source code publicly
> available for the "Current" tree and we will continue to consume it.
> They will not make available the code for the extended parts of the
> tree, just like before.
>
> So, if one is using RHEL and wants to stay on the 6.4 tree, you can andeither
> you can still get updates. If one is using CentOS and wants to stay on
> our 6.4 tree, you get no updates.
>
> 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.
>
> Now, we have had people say it is a strawmnan issue, even here on this
> list .. but if we can change the perception AND more accurately portray
> what a CentOS point release really is (a point in time release of the
> main tree) by changing the way we talk about the name ... while leaving
> the content of the distro exactly as it is, then why would we not want
> to do that.
> either
> The only thing I can think of is that some people actually WANT to
> misrepresent what the point release actually is. That some people
> actually want users to think that 6.4 CentOS and 6.4 RHEL are actually
> the same thing ... which they are not. They are similar for a period of
> time and then radically different later.
>
> How is what I said inaccurate?
So this is the clearest explanation - not sure why it wasn't clearer to
me earlier. I mean I got the basic idea, once RHEL moves on to a newer
point release updates to their previous point releases costs money and
is not available for CentOS to rebuild and maintain an identical tree.either
So as a user that has never paid for RHEL I wasn't 100% aware that this
existed. I've always basically kept my systems up to date just assuming
that the point releases were kind of like Microsoft's Service Pack X.
Having never paid for a fix to be ported to a previous Service Pack
level its not till today that it makes sense that MS would allow clients
to pay for that kind of service.
All this to say is that I never thought I could stay on a point release.
Also I'm wondering if someone doesn't update the centos-release-6.5 rpm
won't they still be getting updates anyway? I just checked it it looks
like you are.
Here's my simplistic suggestion, don't maintain those older trees. One
tree lastest version for the major version. This is the clearest signal
that there is only ever one area where updates occur. Or if there is a
good reason to keep older packages in their own point release, make the
centos-release always point to the 'latest' repo. As in it doesn't
matter if I have centos-release-6.2/6.3/6.4 they always point
at /repo/latest?
--
Nathanael
_______________________________________________
CentOS-devel mailing list
CentOS-devel at centos.org
http://lists.centos.org/mailman/listinfo/centos-devel