Per our conversation on IRC and to give everyone a little context on this... Here is my 2 cents.

Here are the current values:64-bit: "647.1 STD B1 built on Nov-27-2013"32-bit: "7.1 STD B1 Built on Nov-27-2013"

This of course assumes that "64" in the string indicates 'VLocity' and the absence of it indicates 'Vector'.I don't mind this as it is, but roarde is working on something that requires a standard, and I do agree there should be a standard for this. The current string for 'VLocity' confuses me. "647.1" ??

Having said that, I would agree on the following format<DISTRO_NAME> <RELEASE_VERSION> <RELASE_SNAPSHOT> <SPIN> Built on <RELEASE_DATE>With a final string that looks like this

"VectorLinux 7.1 FINAL STD built on 2013-00-00"and"VLocity 7.1 FINAL STD Built on 2013-00-00"

Notice the "VectorLinux" as a single word. This would allow parsing of this file as a 7-piece string for both architectures and the components for the string will be on the same spot every time.

This of course is not without flaws inherent to the way we develop the stuff here. For example, it assumes that if we were to ever produce any other release (such as an ARM spin), it would need a different DISTRO_NAME value. But I refuse to think about that at this moment.

64 [bit] 7.1 [version]? Sounds logical to me. While maybe a bit difficult to read, it does maintain six parts to parse. I like your suggestion in that it is easier for us with eyes (and don't see what we are looking at ) to read.

@M0E-lnx:Thanks for your input here and in IRC. There were only a few more lines on this topic after you had to leave.

There's likely a reason for vector-version to be formatted the way it is now. Personally, I'm convinced the format will both change and be standardized during the coming release cycle. The result will be the same with or without my input, except that it will take more time with my input. Don't read this as "they won't listen" Actually, the opposite is true even in this case. Put another way, I'm happy to wait and see what falls out.

The info I need can be gleaned from elsewhere, which is what I'll do. The only item I don't know how to get otherwise is the build date, which I'll have to take from the last "field" of /etc/vector-version.

The issue isn't "solved", but I've marked it as "withdrawn" with the hope that it won't become more of an issue.

64 [bit] 7.1 [version]? Sounds logical to me. While maybe a bit difficult to read, it does maintain six parts to parse. I like your suggestion in that it is easier for us with eyes (and don't see what we are looking at ) to read.

I can read it just fine. I meant it is odd to parse that into computer friendly parts that make sense to human eyes

Am I right to read this the following way?1: Maj.min version (7.1)2: Edition (STD, Light, SOHO, BB)3: Spin, or release if out of spins (B3, RC1, Gold, LIVE, Deluxe) Not asking which spins we'll have, just the format.4: Release if not above, or the word "built", which flags end of fields except for last, the date.5: If "built" above, "on" here. Other wise "built" or some optional thing.6: Date.

So throw VL<space> on the front, a .iso on the end, substitute hyphens for spaces, and we have our 32-bit ISO name, right?

Another 2 cents....Id say there's an value in following mainstream in the naming of an ISO.Anybody new to VL should be able to instantly choose an ISO from an ftp.Without doing any research!

Therefore the archive folder might include Vlocity, but to a new user of VL wtf is that standing for?Eg. is it an Server edition or what............ you really cant tell, and by that you are obviously not following good community practice.So what im saying is: Vlocity is a dandy name, but use it as a nickname/ showcase. Not as a syntax labeling for the ISO.

And naming by using UPPERCASE letters is cool on the VL-bit but otherwise seams abit bad from esthetic and user perspective. Also remembering a date in your head to type the disto-iso name somewhere seams to me also abit overkill.Short and informative is key.....

I can easily understand why you'd wanna get an easy syntax incorperated in the name.But from my perspective it seams like a much better option to have an "metadata" page in the distro.And by incorperating such, optionaly also can add a bunch of other useful info.Like install-lists-versions, original kernel, date of release, tweaking options and loads of other goodies an programer/ user finds useful.

The position in a meta-page is not necessary to have fixed, but a fixed labeling of names are good for collecting data.For example if you knew that Rel-Date is followed by what you need. It outha be pretty useful right?And by making shore to always update this meta-page for each release it becomes very useful as a dictionary for the distro aswell.Just paste it in changes and no need to reinvent the wheel again, its reuseble in multiple ways.