-----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----- -------------- next part -------------- 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.