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-0007.sig>