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