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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140621/2ffe1eb6/attachment-0007.html>