Re: module _VERSION number scheme proposal

[David Hollander <dhllndr@...>]

> 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...

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".

So let's say there are two problems: resource acquisition, and
behavior assertion. Acquisition should be handled before code is
downloaded, assertion should happen before code is executed. A
post-execution acquisition check relying on a mandated mod._VERSION
protocol doesn't seem very useful.

- David
On Thu, Nov 10, 2011 at 1:24 PM, Thomas Harning Jr. <harningt@gmail.com> wrote:
> On Thu, Nov 10, 2011 at 2:05 PM, David Hollander <dhllndr@gmail.com> wrote:
>>> Why would I want to compare a table to a string if I've got the tables?
>>
>> The primary advantage of comparisons using a hash string over a
>> _VERSION table is it works regardless of whether or not the source of
>> the module is trusted. It also always works for everything, rather
>> than a subset of code with _VERSION set to a table faithfully and only
>> shared via HTTPS\SSH. If the fundamental reason for version identity
>> is to prevent unknown state\non-determinism, the additional advantage
>> of a hash string comparison is that it can also be performed before
>> executing the module in question.
>>
>> The primary advantage of a number time timestamp being set upon
>> redistribution over a _VERSION table, is that it is a metric
>> containing more information. It signals "recentness" in addition to >,
>> <, ==, and can be re-displayed in a variety of formats and orderings
>> without changing the underlying information.
>>
>> - David
>>
> A timestamp is somewhat useless in many cases... unless you pair it
> with other information.
>
> 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... or behavior changes
> that are in spirit with the project, but break assumptions that may
> have been made.
>
> --
> Thomas Harning Jr.
>
>