CentOS 7 and release numbering

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

hi,

Taking on board the community and environment expansion that is taking
place around the CentOS project, the CentOS Board has been considering
how best to accomodate these efforts.

I'm attaching here a plan put forward by the board towards that aim.

Thoughts ? Comments ?

- - KB

- -- 
Karanbir Singh, Project Lead, The CentOS Project
+44-207-0999389 | http://www.centos.org/ | twitter.com/CentOS
GnuPG Key : http://www.karan.org/publickey.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlOSYF4ACgkQMA29nj4Tz1usTwCgr9K0th6XcMzSmjGQvwnbeeiR
KhsAn36gaRbCuGoGzqEa2TN+TDFEEZjR
=GbVM
-----END PGP SIGNATURE-----
Message for centos-devel:

As we approach the release of CentOS 7, the CentOS project board has been
discussing making a change to the way that we name individual CentOS Linux
releases. We've always just adopted the X.y numbering, but it's clear to us
that as we build up the SIG efforts, we need to find a way to allow SIGs
producing variants the ability to stay in sync with their own upstream
timelines, while ensuring that it's always possible to track back to the
release of CentOS Linux they built or deviated from. 

We've been discussing a new versioning scheme in which we'd keep the major
version number from upstream, and append a Year/Month value reflecting when
the corresponding RHEL (or interim CentOS) release shipped. So, if RHEL 7
came out this July, the version name would be CentOS 7.1407. We also feel
this better reflects to users the age of the install.

A change like this would allow CentOS to continue to deliver the core
distribution (a Red Hat Enterprise Linux rebuild) while allowing ourselves
the flexibility to roll in additional enhancements, such as optional repos
and configuration choices included in our installer, with the goal of growing
our commnuity base by delivering value to users and promoting the work of
SIGs.

Finally, a versioning scheme such as this would allow us to version and track
builds that have in the past struggled in the x.y regime (eg. cloud images,
updated at point in time against security vulns or to incorporate vendor
environment changes).

We will continue to match compatibility with tools and projects in our
ecosystem as CentOS has done in the past, particularly since packages and
installed systems would retain metadata about the upstream version they came
from. 

We've pulled together a short FAQ on the issue below.

Thoughts, ideas? Discuss!

***

Q. What are we discussing?

A. In preparation for its next major CentOS Linux release, the CentOS Project
is planning to adopt a new versioning scheme for its releases.

Q. Why a new versioning scheme?

A. Over the past year, beginning with the debut of Xen4CentOS, and continuing
with our efforts to facilitate and encourage the creation of additional
CentOS variants. The CentOS Project has expanded its mission to not only
simply following RHEL, and the Board has identified a need for our versioning
structure to expand as well.

CentOS Linux has always followed the numbering scheme of the Red Hat
Enterprise Linux code base from which CentOS is derived. After each major and
minor version release of RHEL, a CentOS Linux release has followed, bearing
the same major and minor version numbers. 

As we've taken on new projects that build on the CentOS core, and as we
consider how best to promote and make this work available to the broader
community, we foresee that the one or two occasions per year when RHEL point
releases become available will prove too limiting for the increased scope of
the project.

For instance, we've discussed making the work of CentOS SIGs available to
users in the form of optional add-on items in the main CentOS Linux
installer. A user interested in running a set of Ceph nodes could access the
latest version of Ceph by enabling the Storage SIG's repository during the
install process.

A more flexible versioning scheme would allow us to make optional
enhancements available to users on our own schedule, while continuing to
provide the same base CentOS Linux that users rely on.

Q. What sort of versioning scheme does the CentOS Board have in mind?

A. The CentOS Board has devised a versioning scheme that would retain the
major version number from an upstream RHEL release, and replace the minor
version number with a Year/Date value, based on when that RHEL (or interim
CentOS) version was released.

For example, under this system, if RHEL 7 were to ship this July, our release
would be called CentOS-7.1407.

Release names could also include a trailing "-$TAG" element, potentially for
use by SIGs, or for opening up additional options as needed, which can be
debated out over time on the devel list as we get into the rhythm of SIG
releases.

In addition to allowing for more frequent releases, timestamp-based
versioning would also provide more information about a release than do simple
point numbers, communicating “what is latest” without requiring users to
know which point release is most current. Since the CentOS Project has always
targeted its community support at the most up-to-date version of CentOS, we
believe there's value in including this information in the version name
itself.

What's more, a timestamp-name would give SIGs a divergent point where they
can choose to maintain as long as they want until they choose to rebase and
come back to the trunk.

Q. Would this change apply to CentOS 7 only, or would it affect earlier
versions, as well?

A. We're discussing this for CentOS 7 only at this time. It might make sense
to look at adding this flexibility optionally to the 6 tree at a later
point.

Q. Would a new scheme break scripts and tools or otherwise inconvenience
members of the CentOS community?

A. It's a priority for the project to maintain compatibility with scripts and
tools that reference upstream naming, and avoid inconveniencing projects and
individuals in the community. If you foresee issues along these lines, please
raise them for discussion.

Q. If the minor version number in CentOS Linux releases no longer matched the
minor version number in RHEL releases, how would users track the feature
changes that occur across RHEL point releases?

A. Today, figuring out which features and fixes were introduced in a
particular point release of CentOS is a matter of consulting the version
number and looking to a wiki page or other resource for the detailed
information. Under the new versioning scheme, the experience for users would
be the same. The CentOS wiki will include information about each release,
including the particular RHEL version it tracks, as well as information about
the SIG-maintained components available in that release.

Also, information about upstream version from which a package hailed would
remain on CentOS install media and on installed systems as previously done,
which would provide users or scripts another way to discern the upstream
version.

Q. How can I get involved?

A. Please weigh in on the versioning discussion in the centos-devel mailing
list.
_______________________________________________
CentOS-devel mailing list
CentOS-devel-IFYaIzF+flcdnm+yROfE0A@public.gmane.org
http://lists.centos.org/mailman/listinfo/centos-devel