Version numbering

I would like some feedback from the RISC OS community on the topic of version-numbering. We saw how the ROOL/ROL split trashed the version-numbering of the Toolbox modules. I am afraid that I have nobody to blame but myself for the mess that RiscLua’s version-numbering has become. I would like to reboot it, but first I want to canvass others for their opinions and advice, even if they have no interest in RiscLua itself.

One possibility is to have no version-numbering at all: simply use a date instead. That at least tells you the order in which versions appeared. However, in RiscLua’s case it would be useful to give more information: for example, the version of Lua upon which it is based, and the type of platform it can run on ( i.e. does it have VFP or not ). Over the years I have also produced special versions for my own, or other people’s, purposes, some with different arithmetical systems (e.g. !Zahl) or different packaging (e.g. Luna, with error-throwback, with a standard prelude, … ).

Here, for reference, is a quick precis of how standard Lua is versioned.

   The releases of Lua are numbered x.y.z, where x.y is
   the version and z is the release. 

   Different releases of the same version correspond to
   bug fixes. Different releases of the same version
   have the same reference manual, the same virtual machine,
   and are binary compatible (ABI compatible). 

   Different versions are really different. The API is
   likely to be a little different (but with compatibility
   switches), and there is no ABI compatibility: applications
   that embed Lua and C libraries for Lua must be recompiled.
   The virtual machine is also very likely to be different
   in a new version: Lua programs that have been precompiled
   for one version will not load in a different version.

This idealized system is in practice more complicated. When a new version is being developed work versions (w) are produced for the community to play with and test. Then release candidates (rc) are produced, then an alpha release (a) , then a beta release (b) and finally the new version. None of these but the last make it into the archives.

StrongHelp manuals should should reflect in their title the versions of the software which they document. A more contentious issue is to what extent the components of software should be identifiable by the version. For example, the RiscLua package always has two binary files lua, the interpreter, and luac the compiler. If you have two versions of RiscLua in your filing system you can get into trouble if versions of these are not kept distinct. For that reason at some point in the past I decided to add version numbers to their names, to avoid confusion. Then I realized it was more convenient (for me, if not for the user) to keep the names generic. Obeyfiles could then be made version-independent.

What I propose for RiscLua is a resetting of the version-numbering along the lines of

<Lua version><platform><date>

I don’t have a much opinion on the ‘right’ way to do things, but just to note that PackMan (and the Debian packaging system from which it’s derived) have a relatively rich way to record version identifiers (which are not purely numbers) with multiple parts to the version, and a system that is able to work out which one of two is ‘newer’, which is more detailed than a simple ASCII sort. Thus it’s usually possible to craft a version such that the ordering alpha→beta→rc→release is obeyed.

I’ve always felt the RISC OS traditional n.nn version numbering a bit restrictive in this respect. I wonder how *RMEnsure (being the only part of the OS that actually cares about them) handles wacky version strings?