[CentOS-devel] CentOS 7 and release numbering

[Karsten Wade]

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

On 06/07/2014 11:52 AM, Trevor Hemsley wrote:
> On 07/06/14 19:45, Akemi Yagi wrote:
>> As Trevor said, we just say, "CentOS 6.4 is no longer supported.
>> Please update to 6.5". On the other hand, "CentOS-6.1302 is no
>> longer supported. Please update to CentOS-6.1311 because it is
>> June of 2014 today" sounds a bit cumbersome.
> 
> We also lose that 1:1 mapping with upstream where we're often asked
> "is CentOS 6.5 the same as RHEL 6.5".

I want to start by acknowledging that the primary concern here is
taking care of existing users, and not scaring people away because
they think something is going to change about the plain vanilla core
rebuild.

The best thing we can do there is to actually prove that's the case,
which I expect will happen with the coming CentOS 7 release. The huge
increase in transparency around the distro build is an example of
providing that assurance - it is now auditable and proveable that the
Project doesn't change anything meaningful (outside of artwork) for a
given set of RHEL releases or packages.

> Are you aiming to release new isos for every update? or every
> month? If not then I suggest we stick with the current naming
> convention as it fits better with the release of the media.

That's a possibility (in my mind at least :) ), but what's really
important is that example is why we need future proofing built in to
the versioning scheme. The goal here includes doing this change one
time with room for future needs.

One of my biggest goals in joining this project is to grow the user
base for CentOS Linux across the open source ecosystem, but the user
base for plain derived-from-RHEL growth is beginning to flatten (or
even drop-off.) The biggest coming growth is in variants, e.g. people
wanting to 'yum install openstack' and just get running.

We need something right now to deal with the variants so it's clear
when one has deviated from the core pathway. The last thing we want is
users thinking that installing the variant with OpenStack that
requires a new kernel, qemu, etc. is the same as an X.y it's based on.
It's clearly different technically, community support has to come in a
different pathway (such as from the SIG), and we don't want a dozen
variants-of-confusion because it says e.g. "6.5-cloud-openstack" when
it's really "6.5 bits + kernel bits cherry-picked from the CentOS 7
tree and back-ported."

So back to your question above as an example, if the Project gets to
where it wants to roll a new ISO or installer every month or quarter
to bundle in all the updates from EL (instead of "Install CentOS x.y
and then update to the latest") -- with the idea of doing that respin
 based on user demand and need -- then the X.y scheme falls down. We'd
have to add a .z to it, and then we'd be confusing what is derived
from RHEL because we'd be go from using an identical scheme to one
that no longer meant the same thing as upstream's versioning scheme.
We'd have to update the versioning scheme again, with all the
associated headache.

Instead with X.YYMM we have a single indicator of the point in time,
it's easily referenceable against the .y from upstream, and it works
going in to the foreseeable future. As a practice, we would have a
wiki page that identified what was in a given X.YYMM release, to
include what was the RHEL X.y, as well as any other /possible/
additions in that release. If the project decided to roll out an
interim update to e.g. the core installer to include a new repo from
Ceph[1], it could do that as a bump of the YYMM, and still have the
next YYMM line up time-wise with the upstream X.y release.

- - Karsten

[1] An argument I hear against rev'ing the installer in this way is,
"Why bother putting the repo in the installer when one only has to
'yum install URL_for_repo_package'". It's pretty well proven by UX
folks that at each additional step in a task there is the potential
drop-off of interest. Simply put, that additional 'yum install' step
v. "check a box in the installer" represents a % drop in potential
users, who then jump over to the other thing that makes it that much
easier to get up and running with their cool technology. This is
partially because the interest is in the cool technology and not the
underlying platform, so forcing them to do the work at the platform
level to get to the technology means a loss of interest in a
measurable percentage of folks.

FWIW, my argument applies to why I'm in favor of regular respins of
the minimal ISO and/or the full ISO to include updates with a X.YYMM
scheme - "grab all the latest" v. "install then update" is an example
of another step that people stumble against and some silently segfault
and go away.

- -- 
Karsten 'quaid' Wade        .^\          CentOS Doer of Stuff
http://TheOpenSourceWay.org    \  http://community.redhat.com
@quaid (identi.ca/twitter/IRC)  \v'             gpg: AD0E0C41
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlOTboMACgkQ2ZIOBq0ODEGEhgCgk56FSpeefdY6kQ6oz58KSLTC
hYUAoOWr3Q03RU9RaZ8nxhEDWn7ptVLH
=04xK
-----END PGP SIGNATURE-----