> > 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. Tim