Am 07.06.2014 17:32, schrieb Johnny Hughes: > We think this system conveys exactly what we want to project with our > versioning system. For CentOS-6 the releases would have been: > > 0. CentOS-6.1011 > 1. CentOS-6.1105 > 2. CentOS-6.1112 > 3. CentOS-6.1206 > 4. CentOS-6.1302 > 5. CentOS-6.1311 > > As you can see, the minor numbers also match in the list (6.3 matches > 6.1206) ... it's very easy to see that there are 6, 7, 7, 8, and 9 > months between releases, etc. > > Thoughts? I think that would break at least my configuration management. We do have Puppet modules that require at least a certain "lsbdistrelease" and that works fine on RHEL and CentOS so far. With the other naming scheme we'd have to write two checks: one for the RHEL and one for the CentOS release number. And even worse: "stock modules" written for CentOS wouldn't work on RHEL (and vice versa) out of the box anymore. When we have a monthly re-release of the latest version with all updates integrated. Do I have to upgrade the vmlinuz/initrd.img on my tftp every month? In the past we had to do that whenever there was a new point-release, so how can I determine wether this has to be done or not in the new scheme? Having shared my concerns, I'd like to suggest a non-invasive way of doing things. Maybe we can have the usual point-releases as installtrees (just the way it has been for ages) and have the X.Y as lsbdistrelease and in /etc/redhat-release But could then add the release date in the codename field like this: """CentOS release 6.3 (June 2012)""" Historically the codename-field is unused in centos, so that wouldn't hurt at all. Also we could then respin the Install ISOs on any schedule we like, and call them e.g. "CentOS-6.3-June2012-x86_64-dvd1.iso". The SIGs can then decide weither to build based on the respinned ISO or based on the original tree. Pro: - backwards compatible release numbering - still tracking upstream - intermediate releases still possible (through ISO respinning) - number of installtrees on vault.c.o limited to the upstream releases - creation of intermediate update spins (i.e. monthly update-releases) can be moved into a SIG as it is just "yet another respin" Con: your thoughts? -- Solvention Ltd. & Co. KG St.-Sebastianus-Str. 5 51147 Köln Tel: +49 2203 989967-0 Fax: +49 2203 989967-9 http://www.solvention.de mailto:info at solvention.de