[CentOS-devel] CentOS 7 and release numbering

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-0003.html>