[CentOS-devel] CentOS 7 and release numbering

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