[CentOS-devel] CentOS 7 and release numbering
Andreas Rogge
a.rogge at solvention.de
Sun Jun 8 21:49:48 UTC 2014
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
More information about the CentOS-devel
mailing list