-----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-----