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 06/09/2014 02:55 AM, Stephen John Smoogen wrote:
>
>
>
> On 8 June 2014 17:01, John R. Dennison <jrd@gerdesas.com
I am main admin of the CentOS Facebook group. In about two weeks we will> <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.
>
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