I've yet to see the technical argument for this release numbering change, the closest thing I've seen is... > A clear example of what the datestamp tries to workaround is > yesterdays docker updates ( and the AMI and GCE images etc ) that were > done to CVE fix openssl content. These are not marked as a point at all, > just a centos-6-x86_64-20140609 ( and in most cases, the link that > people hit is for centos-6-x86_64 ...and that has nothing to do with the Core OS. As far as I can tell it's not even a technical issue but a website/people presentation issue. This could also break system and configuration management tooling as well. I have servers with their OS configuration managed by Puppet and chef recipes controlling their application config (don't ask :^) ). Those systems "shouldn't" barf but we all know some naughty person will have written their own regex to parse up and switch case on the contents of /etc/redhat-release or whatever. I'd be loathed to split it into two tracks either, one for RHEL numbering and one for CentOS. I appreciate this isn't a concern of the OS devels directly as such. Will this version format be compatible with RedHat Satellite, Spacewalk or Katello etc? We were looking at actually buying Satellite at $work as we migrate off of Spacewalk but until I know this is all compatible there's no way I can contemplate any recommendation for investment in Satellite and/or several weeks of setting up Katello and then a migration effort to move the old systems out of Spacewalk if I have to have separate versions. This sort of thing really needs to be confined to a SIG (or some sort of test/beta) or come via RHEL themselves. If it comes from RHEL it will be compatible with their own (and others would follow with their) tooling or at least if it's trailed outside of Core people can test it separately. As is, we now have to wait until any new CentOS numbering is proven to be compatible with RHEL numbering in other tools and then determine if it's viable to continue using both in-step. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140612/16152f9d/attachment-0007.html>