[CentOS-devel] CentOS 7 and release numbering

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/10/2014 10:33 AM, Johnny Hughes wrote:
> No one is saying that anything in the Core OS is changing

Except the version scheme.

> The issue is, people think they can run CentOS-6.4 after 6.5 is
> released and it is the same as running RHEL-6.4 AUS/EUS ... and its
> not.

No, it's the same as running RHEL without AUS or EUS.

> Our numbering is not like their numbering and that is causing
> massive confusion that we need to fix.  One can absolutely,
> positively not stay behind and have security.  It is very
> dangerous.

Believe me, I understand where you're coming from, I see the same
people day in and day out come into IRC that you see who are on some
old version of CentOS and think that's fine.  But inevitably, their
issue is not that they ever thought that the version they were on is
still getting updates, because inevitably they are not updating at all
otherwise they would be on the most recent CentOS version.  It is
absolutely wrong to think that changing the version scheme will
address this in any way, it simply won't because those types of people
have no concept about keeping their OS up to date regardless of what
the version string is.

And just because you change to a date-based version absolutely does
not tell anyone that the older "dates" are EOL.  People will see this
as being no different to distros such as Ubuntu (forgive me $DEITY)
which uses date-based versions, but still has new releases every six
months and any given release is supported for a minimum of two years
up to five years for their LTS releases, so you could be on Ubuntu
10.04 and it is still current and supported, what's to stop people
from equating the CentOS dates to this and thinking, "CentOS has a 10
year lifespan so my CentOS 6.1312 release should be good until
December of 2023"?

Granted the above is unlikely but just as much is the idea that
someone will think that their release of CentOS is expired just based
on a YYMM release date.  All it is is making a completely unrelated
change with wishful thinking that people who don't know to update or
understand why they should have to will be any more likely to update
because you make some crazy change to the version scheme.

> Add to that the fact that the SIGs also may need to have a new
> installer be created between RHEL releases, so we may (or may not
> ... only time will tell) need to create some new install trees.

I will re-iterate here that you are making changes to the core to
accommodate SIGs, changes that you haven't even demonstrated a
legitimate need for.  The issue with the SIGs can be addressed with
versioning that would be specific to the SIGs and then not have to
push their needs onto the core distro.

> None of that adds packages into the os/ or updates/ directory that
> is not in RHEL ... that will be the same and people will have to
> opt-in to get anything that is not Core .. just like they do now.

No but it will make subtle changes to key files in core packages that
could cause compatibility issues with 3rd-party software.  I have
already described how this can happen and to me that is certainly a
deviation from RHEL that should not be dismissed.


Peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTlmn2AAoJEAUijw0EjkDvQrcH/3JcKNkWvr5GimhodZjgmD/M
yCMHJov1barqDdN1uSGeEuZ9xjxXEYREMBaclNqo4uRAHRxMTlcO7NIUOYfYMkKT
8rJRq3KdN999FDf9XX/jhy1sqZRyE/Svd8+jz3r6axhTiATh5Z2MT9LywfNpuKUU
SndbWlhR/dBv0bHdcuSkVo3SVdgbDvMO3/NHkQ/jM6jMRhUIPMX+/ytvPQzcd3ZH
TRFjDFIclf9ndtD8yW7b7OexydrAsdInCN1teTz8hS4+HppOkhpG3qn2o/JjfmmN
Pb9tGbrZwD+txCa7Y3kx1nmc2eMmR+t4yNDwwEaoSOkXq+Y1iYrDb04g8tnIMBU=
=derv
-----END PGP SIGNATURE-----