Re: module _VERSION number scheme proposal

[David Manura <dm.lua@...>]

On Thu, Nov 10, 2011 at 5:05 AM, David Hollander <dhllndr@gmail.com> wrote:
> If the problem is not one of uniqueness, but of temporal sequencing,
> my second suggestion is to use a "os.time()" timestamp property.
On Thu, Nov 10, 2011 at 3:28 PM, David Hollander <dhllndr@gmail.com> wrote:
>> Some developers maintain multiple versions of the same software over
>> time and do not expect everybody to hop onto the latest and "greatest"
>> version since there may be incompatible API...

Relying on the file modification time can be too fragile.  Tools like
git/Mercurial don't fully preserve it, it can get reset on
copying/downloading, text editors don't display it, and it depends on
the file system implementation.  (There is also the issue that a
patched version 1.2.3.1 may be authored after 2.0.0, but see my
comments on capability detection below.)

> This is definitely important. But it seems to be a resource
> acquisition problem, far upstream of "module already downloaded,
> module already loaded and ran os.execute 'rm -rf *', let's
> programmatically check mod._VERSION to see if I even want this".

For reasons such as this, it's good module design that `return
require'foo'._VERSION` have (nearly) no side-effects other than to
return a version number.  But if you really did not trust a module to
behave sanely, you could load it into a sandbox, do source code
analysis to infer the value of the variable `_VERSION`, or have a
human check it.  The same applies to `_NAME` or to enumerating the
public functions provided by the module.

One purpose of `mod._VERSION` in the first place is to facilitate a
client of `mod` in knowing how to invoke the interface of `mod`
regardless which version is installed.  So, rather than asking "do I
want this?" the client code is often asking "what have you provided
me?"

Capability detection can be preferred over version detection [1]
though, so ideally we would perhaps detect capabilities of a module
(e.g. `mod.foo ~= nil`) rather than testing `_VERSION`.  Some
capabilities may be difficult to discover (e.g. obscure bugfixes), so
relative timestamp comparison can help.  In this light, I wonder if
Lua went wrong in storing 'Lua 5.1' in `_VERSION` rather than e.g.
'5.1.20111029'.  It's easy to differentiate between 5.1 or 5.2 by
capability detection, and you need to do that anyway to further
differentiate between 5.2 with and without 5.1 compatibility options.
However, testing for whether a certain patch is applied [2] for a bug
that might crash the Lua is not as easy without a timestamp or patch
level in the version number to compare against.

[1] http://lua-users.org/lists/lua-l/2011-07/msg00084.html
[2] http://www.lua.org/bugs.html