On 20 June 2014 10:43, Tim Bell <Tim.Bell at 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 -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140620/3180c0c1/attachment-0007.html>