On 20 June 2014 10:43, Tim Bell Tim.Bell@cern.ch wrote:
So, for all periods outside the active time that a tree is live, the
CentOS 6.4 tree
is radically different than the RHEL 6.4 tree. That is the issue I want
to address.
CentOS 6.4 does not equal RHEL 6.4 ... and it is especially tree after
the 6.5
release. I think that there is obviously an issue in perception that
people think
they can stay on an old tree and get the same thing they would in RHEL,,
and
they can't. They can't on CentOS ... they can't on Scientific Linux, they can't on
any of the
rebuilds.
From my understanding, RHEL by default gives the same (i.e. you follow
the tip) unless you turn off yum. It is only if you pay extra for EUS do you get the branch updates.
From what I can see,
- There is interest in clearly marking the release with a date to show
from which source it is taken when the base code was built.
- There is interest in maintaining some correspondence. As you mention, it
is currently like that for Scientific Linux CERN and we have not encountered confusion with our community.
How about we take the following approach
- We define the point release as being the one that Red Hat define as
their point release in the code from which the build is derived (i.e. the contents of redhat-release in the git repo). This is the closest indication of the correspondence with RHEL.
- We define a date based extension which indicates the date that the build
was done.
This would produce a version number along the lines of 7.0.1406 which would not be confusing to those who have been using the distros previously and indicate the time based nature of the work.
To extend this a bit further I was going to say
7.0.core.201406 # Rather not be Y2100k compliant :) 7.0.storage.201407 7.0.openstack.201408
that way it covers everything:
Upstream release: 7 Upstream starting point branch: 0 Downstream SIG: core, storage, openstack, desktop, etc etc Downstream Release Date: 201406, 201407 etc
The files that need to be parsed by tools by vendor tools (eg Oracle wanting 6.5 and not running on 6.4) can have the two parts that are needed. The parts that community support members need (which SIG was this and which releasedate in case of say openstack doing weekly snapshots.. ) are there.
And no I am not a stickler on 201406 versus 1406 .... just like my ISO8601