[CentOS-devel] CentOS 7 and release numbering

[Dan Porter]

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