[CentOS-devel] CentOS 7 and release numbering

[Jake Shipton]

On 07/06/14 16:32, Johnny Hughes wrote:
> <Snipidy Snip Snip Snapper Snap BOOM>
> 
> We think this system conveys exactly what we want to project with our
> versioning system. For CentOS-6 the releases would have been:
> 
> 0.  CentOS-6.1011
> 1.  CentOS-6.1105
> 2.  CentOS-6.1112
> 3.  CentOS-6.1206
> 4.  CentOS-6.1302
> 5.  CentOS-6.1311
> 
> As you can see, the minor numbers also match in the list (6.3 matches
> 6.1206) ... it's very easy to see that there are 6, 7, 7,  8, and 9
> months between releases, etc.
> 
> Thoughts?
> 

In my honest opinion, I can see your logic behind this however I feel
this change would cause more harm than good.

First and foremost, If I have to ask an employee "What version of CentOS
is that server on?"

A response of "It's on version six point five upgraded from six point
four" tells me It's up to date and matches RHEL.

A response of "It's on version six point one one one two upgraded from
six point one one zero five" makes me look at them with an odd face and
does not immediately tell me if the machine is up to date as I would
have to pull out a calendar and check dates to find the RHEL release
that it matches.

Additionally, you may have confusion when it comes to international
dates too because different countries have different date formats.

For example, in the UK we have the following format: Day-Month-Year, in
the US the date format is: Year-Month-Day.

So some users may confuse 6.1311 as 6.<Month><Year> instead of what it
actually is due to their local date format.

Essentially, that method of versioning would make it a pain in the other
end.

I feel the solution to your problem is much simpler.

Let's say you have a SIG which is based on C6.5 the easiest way to allow
people to know this is by versioning the SIG as follows:

<Signame> Version 6.5_1.3 (Or 6.5-1.3)

So it becomes:

<Signame> version <CentOS Version>_<Sig Version> (or <CV>-<SV>)

In this method, you are showing both version numbers and saving a whole
lot of headaches.

If you over-complicate things then users will just get confused or old
management will not be happy and end up complaining about admins talking
gobbledegook about versions.

Although we normally don't care if management is happy or not but
besides that's the point :-P (I'm the boss in our company so I can say
that and get away with it, no one can sack me :-D)

Keeping versioning in-line with RHEL's versions is your best bet in my
opinion. Naturally of course, if versions for SIGs have to be changed to
be made more clear, then by all means proceed, but only change the SIGs
versions, not the core's versions as otherwise it just causes confusion
as the current versioning of core works just fine.

Anyhow, just putting my opinions in :-).

Kind Regards,
Jake Shipton (JakeMS)
GPG Key: 0xE3C31D8F
GPG Fingerprint: 7515 CC63 19BD 06F9 400A DE8A 1D0B A5CF E3C3 1D8F