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:
- CentOS-6.1011
- CentOS-6.1105
- CentOS-6.1112
- CentOS-6.1206
- CentOS-6.1302
- 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?