Personally I like Jake Shipton’s suggestion. I have been a CentOS user for many years, from 4.x onwards, for both business use and personal projects. I prefer matching RHEL versioning - if RHEL is using 7.1, 7.2, etc. we should use that. There’s two systems of sub-versioning I like: 7.1-1.15, 7.2-1.24, etc. (SIG version) 7.3_1139, etc. (SIG revision) If CentOS aims for full binary compatibility, any tool that checks for RedHat version should relay the red hat version string (such as etc/redhat-version). I think that /etc/centos-version) should show the SIG version as well. If anything, I dislike the YYMM format suggested above, for two reasons. a) Date format could be confused (like Jake said) and b) this limits us to one patch release a month. Although an uncommon occurrence, I’d prefer to use a format that doesn't have this limitation. My two cents. Dan On 9 June 2014 09:12, Ljubomir Ljubojevic <centos at plnet.rs> wrote: > On 06/09/2014 02:55 AM, Stephen John Smoogen wrote: > > > > > > > > On 8 June 2014 17:01, John R. Dennison <jrd at gerdesas.com > > <mailto:jrd at gerdesas.com>> wrote: > > > > On Sun, Jun 08, 2014 at 05:20:47PM -0400, Carl Trieloff wrote: > > > > > > I've read through the the responses so for and the main concern > > seems to > > > be understanding the linkage between upstream and CentOS. Am I > > correct > > > in that? > > > > That and the fact that it has been stated repeatedly that the CentOS > > core product will _not_ change and what is being discussed here is a > > change to that same core product. > > > > > > Well I think this is more about defining what people think of as change > > and no change. Being the internet I am sure there are some set of people > > who will define any new release as being a change in the core product > > and thus a breakage. And there will be people who are at the other end > > of the spectrum and ok with all the change in the world as long as the > > name is CentOS and the first number is similar to the RHEL name. And > > then there are a ton of definitions of what is change and what isn't in > > between. > > > > So a better discussion is I think people defining what they would accept > > as being 'change' and what is not change. The board has stated their > > view of change and various users are defining in a piecemeal way what is > > their definition of change. I think that it might be better if the users > > state a bit clearer so that the board has a definite idea of where the > > lines are. > > -- > > Stephen J Smoogen. > > > > I am main admin of the CentOS Facebook group. In about two weeks we will > have 10.000 members. There are only 3 of us to properly respond, and we > are on the frontline of newbie wave, those that never ever used IRC, > forums or mailing lists. We have trouble just to explain that they need > to upgrade to latest. Imagine the chaos that would come from date > versioning. I think my ultimate response would be to just stop > administering that group, period. Even now every 5-10 days I have to > reiterate all basic steps even thou it is pinned in first post. People > just do not read or learn anything they can get away with. They are > lazy, and as it was previously said, every even small complication will > repulse them away from CentOS. > > AS for the "definition" of change, It was made simple by devel guys. > There can not be no changes, beside most necessary, that distance CentOS > from RHEL. What RHEL publishes CentOS must also publish, with only as > minimal as possible changes. CentOS distro is not allowed to carry any > 3rd party repo files because RHEL does not have them, and CentOS project > strives to be binary compatible with RHEL. > > And then suddenly, after CentOS Project members get payed by Red Hat > CentOS project starts looking like Fedora respins, braking with RHEL > numeration, CentOS distro becomes experimental platform for software Red > Hat wants to push for better market share via respins, and we are left > explaining to every single newbie why that had to be done. > > If SiG's are going to be so problematic, then they can devise their own > versioning scheme, because if they are going to create such difference > from core CentOS distro then just call them CentOS-like distro's and be > done with it. They are either CentOS with 3rd party repositories or will > be just using SOME CentOS-produced packages for better use of available > resources. Period. > > > -- > Ljubomir Ljubojevic > (Love is in the Air) > PL Computers > Serbia, Europe > > StarOS, Mikrotik and CentOS/RHEL/Linux consultant > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140609/3e46659c/attachment-0007.html>