[CentOS-devel] CentOS 7 and release numbering

[Philip Mather]

Morning all,
   I have to concur with Trevor and Kay on a lot of points...


> The more CentOS feels exactly like "RHEL - but without
> support", the more people understand it and take stock.


There's an inevitable amount of trepidation around any change in direction
from a Community Project and the current changes for CentOS are pretty
significant, it seems wise to keep a clear and distinct link between CentOS
and RHEL to allay any such concerns.

In any "What does this mean to us?" conversation it would be very soothing
to be able to say something like "Well, we'll move from CentOS 6.$x to 7.$y
and that will continue to maintain compatibility just as before but the
community will also be doing $z as well etc...".


> Seems better to work around issues with the RHEL versioning scheme than to

&

> If the SIGs need a versioning scheme for the layers on top of the base
> o/s then the new naming scheme sounds good for those but the core o/s, I
> believe, should stick with mirroring upstream release numbers.


At $work we do actually use a %YYYY%MM postfix in our Spacewalk set-up to
keep monthly snapshots and I think the idea in the abstract is a good one
(although YYYYMM is specifically excluded from ISO8601 for clarity
reasons). However we add the date ourselves "independently", is there any
reason the SIGs couldn't use the -$TAG in the same way? Allowing the core
to remain unambiguously equivalent.

It might even allow different SIGs to try different formats/options, find
the best and then transfer control of the -$TAG format back up-stream to
the CentOS Project centrally if there's agreement and then around(?)-stream
to RedHat themselves? It could save their support guys any confusion of the
future RHEL9 with the truly legacy "Red Hat Linux 9", a point I vaguely
remember someone mooting about 7. :^)

-- 
Regards,
   Phil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140608/680a2e62/attachment.html>