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@plnet.rs wrote:
On 06/09/2014 02:55 AM, Stephen John Smoogen wrote:
On 8 June 2014 17:01, John R. Dennison <jrd@gerdesas.com mailto:jrd@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@centos.org http://lists.centos.org/mailman/listinfo/centos-devel