This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Re:Obfuscation

Posted by: Anonymous Coward on June 14, 2005 03:37 PM
>> Besides, that information doesn't belong in a version number, it belongs in the program's documentation (Functional specs, technical specs, and/or user docs).

Well, the intent is, I believe, that this scheme allows certain correct automations to take place with some tools. I am not in love with the scheme, but many other ways of labeling versions, while they look nice and convey some simple concept to most users, do not convey all the required info to allow certain types of automation (that are carried out guided by the file name or by some binary format info or other and not by "technical specs" or by "user docs").

Who says we can't have an external and an internal (or >2) versioning schemes? Or for that matter, metadata that can be added in various places to convey various meanings.

An earlier poster wrote at length about the Reiser filesystem (and OS/400 and others). My informed guess is that Reiser allows a lot more information about a file to be held outside the file (in filesystem domain). In this case, you could solve many of these problems by simply having as many attributes as necessary to hold as much info as was required/wanted. In such a scenario, it would be easier to have display tools, search tools, viewers, etc, of the filesystem come in more flavors that were to the liking of more people. In all cases, files may appear, sort, etc, differently to different people but each would still have the same files and be able to get the same milage out of them.

EG, I could display on my files-viewer nice short names when viewing some directory (or as the result of some query). In the case of apparently multiple files with the same name (eg, 2 libraries under<nobr> <wbr></nobr>/usr/lib that are missing the typical version extensions, or 2 files named the same but recognized as different to the system, differing in other (invisible) metadata), my viewer would be set up so that hovering the mouse over the file would show some customized amount of the metadata<nobr> <wbr></nobr>... for example: the "." extension, the author, the size, the version, the lib or distro or app or desktop compatibility code, the upgrade url, the origin package url, the last modification author or user or app or process, an alternative icon (or music/3d-pic/video-clip) selection list, last action, suggested actions, last 10 sentences/characters in the file, the programming language or file class, file-project homepage, previous personal notes about the file, etc. --- all of these things would of course need to be standardized to some extent. Standardization of various info about files is what seems to be in short. [someone else also posted about having an internet RFC for versioning... similar spirit as here.]

A lot of libraries programmers use allow searching uniquely for a file based solely on the name (considering the parent hierchy of directories to be part of the name). This would have to be revamped somehow if we were going to de-emphasize the overloading of file names (in order to convey quick-and-dirty file metadata.. for searching, sorting, categorizing, etc) and insist that all the "invisible" metadata be parameterized in standard system function calls. Certainly, this *may* complicate the application interface to the filesystem. Likewise programmers would have to change long-established habits. [the reiser post mentioned earlier also indicates that this meta-info is currently found within files (eg, config files); however, as a shortcut, the actual filename is often overloaded with meanings.]

Note too that developers prefer to be most efficient at developing what they have chosen to do. They are scraching their itch and versioning is not always high priority, especially if they have to reinvent the wheel and there is no standard. Also, there are many surprises the crop up in software development in general. Apparently, versioning hasn't been standardized and "taught" for one reason or another. To deal with the unexpected, sometimes the versioning scheme chosen is what gets versioned.

#

Return to Decline and fall of the version number