module _VERSION number scheme proposal

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

module _VERSION number scheme proposal

David Manura
I propose the following scheme for the _VERSION [1] variable in modules:

  dotnum ::= [0-9] [0-9] [0-9]
  version ::=  dotnum { '.' dotnum }

Examples of valid versions include '001', '001.234', and '012.001.001.001'.

Properties of scheme include

  - Versions can be compared by simple string comparison (no special parsing).
  - Versions can contain an arbitrary number of dotted numbers
    (though typically 2 - 4).
  - By using strings, it is not subject to numerical rounding, like storing
    versions in floating point numbers, and it even works when Lua is compiled
    with an integer number type.
  - Dotted numbers are unlikely ever to wrap around (exceed 999).  In the rare
    case you do get to '001.999', then either do '001.999.001' or '002.000'.
    If you get to '999.999.999.999' (which is only of theoretical concern)
    then either rename your project (starting at version zero again)
    or use '999.999.999.999.001'.
  - Hopefully keeping things simple this way avoids the path of Perl [2].
  - Version numbers remain relatively readable and also sort nicely.
  - The project name is *not* included in _VERSION
    (e.g. unlike _VERSION = "Copas 1.1.7").

Some optionally allowed variants might include

  - It's not required to stick with three digits per dotted number,
except for the
    first one.  Say you have a pre-1.0 release that versions only with the
    date stamp.  You could use '000.2011.11.07' as long as you follow this
    date scheme when the first dotted number is '000'.  When you
    increment the first dotted number to '001', you may follow a different
    scheme like '001.000'.  Simple string comparisons must still work:
    '001.000.000' > '000.2011.11.07'.
  - It's not required to only allow numbers.
    1.0beta2 might be expressed like '000.999.b2'.  String comparisons still
    work.  For example, '001.000' > '000.999.b2' > '000.999.a3'.

[1] http://lua-users.org/wiki/ModuleVersioning
[2] http://www.dagolden.com/index.php/369/version-numbers-should-be-boring/
[3] http://en.wikipedia.org/wiki/Dot-decimal_notation

Reply | Threaded
Open this post in threaded view
|

Re: module _VERSION number scheme proposal

Daurnimator
On 8 November 2011 16:27, David Manura <[hidden email]> wrote:

> I propose the following scheme for the _VERSION [1] variable in modules:
>
>  dotnum ::= [0-9] [0-9] [0-9]
>  version ::=  dotnum { '.' dotnum }
>
> Examples of valid versions include '001', '001.234', and '012.001.001.001'.
>
> Properties of scheme include
>
>  - Versions can be compared by simple string comparison (no special parsing).
>  - Versions can contain an arbitrary number of dotted numbers
>    (though typically 2 - 4).
>  - By using strings, it is not subject to numerical rounding, like storing
>    versions in floating point numbers, and it even works when Lua is compiled
>    with an integer number type.
>  - Dotted numbers are unlikely ever to wrap around (exceed 999).  In the rare
>    case you do get to '001.999', then either do '001.999.001' or '002.000'.
>    If you get to '999.999.999.999' (which is only of theoretical concern)
>    then either rename your project (starting at version zero again)
>    or use '999.999.999.999.001'.
>  - Hopefully keeping things simple this way avoids the path of Perl [2].
>  - Version numbers remain relatively readable and also sort nicely.
>  - The project name is *not* included in _VERSION
>    (e.g. unlike _VERSION = "Copas 1.1.7").
>
> Some optionally allowed variants might include
>
>  - It's not required to stick with three digits per dotted number,
> except for the
>    first one.  Say you have a pre-1.0 release that versions only with the
>    date stamp.  You could use '000.2011.11.07' as long as you follow this
>    date scheme when the first dotted number is '000'.  When you
>    increment the first dotted number to '001', you may follow a different
>    scheme like '001.000'.  Simple string comparisons must still work:
>    '001.000.000' > '000.2011.11.07'.
>  - It's not required to only allow numbers.
>    1.0beta2 might be expressed like '000.999.b2'.  String comparisons still
>    work.  For example, '001.000' > '000.999.b2' > '000.999.a3'.
>
> [1] http://lua-users.org/wiki/ModuleVersioning
> [2] http://www.dagolden.com/index.php/369/version-numbers-should-be-boring/
> [3] http://en.wikipedia.org/wiki/Dot-decimal_notation
>
>

I think a system where everything is a number would be much better:
 - They can be used directly in comparisons without any forethought
 - They can be almost arbitrarily large (as long as it fits in a double)

They don't need any regulations; as they are a native lua type - to
check if a module conforms you can just use type(mod._VERSION) ==
"number"

Reply | Threaded
Open this post in threaded view
|

Re: module _VERSION number scheme proposal

Vadi

Neither of these are particularly human friendly.

Why does it have to be triple digits and not trimmable?

On Nov 8, 2011 4:56 PM, "Daurnimator" <[hidden email]> wrote:
On 8 November 2011 16:27, David Manura <[hidden email]> wrote:
> I propose the following scheme for the _VERSION [1] variable in modules:
>
>  dotnum ::= [0-9] [0-9] [0-9]
>  version ::=  dotnum { '.' dotnum }
>
> Examples of valid versions include '001', '001.234', and '012.001.001.001'.
>
> Properties of scheme include
>
>  - Versions can be compared by simple string comparison (no special parsing).
>  - Versions can contain an arbitrary number of dotted numbers
>    (though typically 2 - 4).
>  - By using strings, it is not subject to numerical rounding, like storing
>    versions in floating point numbers, and it even works when Lua is compiled
>    with an integer number type.
>  - Dotted numbers are unlikely ever to wrap around (exceed 999).  In the rare
>    case you do get to '001.999', then either do '001.999.001' or '002.000'.
>    If you get to '999.999.999.999' (which is only of theoretical concern)
>    then either rename your project (starting at version zero again)
>    or use '999.999.999.999.001'.
>  - Hopefully keeping things simple this way avoids the path of Perl [2].
>  - Version numbers remain relatively readable and also sort nicely.
>  - The project name is *not* included in _VERSION
>    (e.g. unlike _VERSION = "Copas 1.1.7").
>
> Some optionally allowed variants might include
>
>  - It's not required to stick with three digits per dotted number,
> except for the
>    first one.  Say you have a pre-1.0 release that versions only with the
>    date stamp.  You could use '000.2011.11.07' as long as you follow this
>    date scheme when the first dotted number is '000'.  When you
>    increment the first dotted number to '001', you may follow a different
>    scheme like '001.000'.  Simple string comparisons must still work:
>    '001.000.000' > '000.2011.11.07'.
>  - It's not required to only allow numbers.
>    1.0beta2 might be expressed like '000.999.b2'.  String comparisons still
>    work.  For example, '001.000' > '000.999.b2' > '000.999.a3'.
>
> [1] http://lua-users.org/wiki/ModuleVersioning
> [2] http://www.dagolden.com/index.php/369/version-numbers-should-be-boring/
> [3] http://en.wikipedia.org/wiki/Dot-decimal_notation
>
>

I think a system where everything is a number would be much better:
 - They can be used directly in comparisons without any forethought
 - They can be almost arbitrarily large (as long as it fits in a double)

They don't need any regulations; as they are a native lua type - to
check if a module conforms you can just use type(mod._VERSION) ==
"number"

Reply | Threaded
Open this post in threaded view
|

Re: module _VERSION number scheme proposal

David Manura
In reply to this post by Daurnimator
On Tue, Nov 8, 2011 at 1:55 AM, Daurnimator <[hidden email]> wrote:
> I think a system where everything is a number would be much better:
>  - They can be used directly in comparisons without any forethought
>  - They can be almost arbitrarily large (as long as it fits in a double)
> They don't need any regulations; as they are a native lua type - to
> check if a module conforms you can just use type(mod._VERSION) ==
> "number"

True, but on the other hand:

  - The type used for Lua numbers is undefined (could even be integer
or single precision non-IEEE float).
  - There is not a unique way to format a number as a string.
_VERSION=0.000010; print(_VERSION) --> 1e-5.
  - You still need padding.  Using 1.10 > 1.09 rather than 1.10 > 1.9
is not that bad, but representing things like 1.0.0.7 with 1.000000007
suffers from readability due to counting zeros.

You could alternately use positive integers (1,2,3,...), but this
prohibits later inserting a version between older version numbers
(e.g. for patches).

Reply | Threaded
Open this post in threaded view
|

Re: module _VERSION number scheme proposal

David Manura
In reply to this post by Vadi
On Tue, Nov 8, 2011 at 1:58 AM, Vadim Peretokin <[hidden email]> wrote:
> Neither of these are particularly human friendly.
> Why does it have to be triple digits and not trimmable?
>> On 8 November 2011 16:27, David Manura <[hidden email]> wrote:
>> > I propose the following scheme for the _VERSION [1] variable in modules:
>> > Examples of valid versions include '001', '001.234', and
>> > '012.001.001.001'.

It is a trade-off.  The main intention of the zero padding is to allow
versions to be compared by simple string comparison, i.e. without any
external version library like verlib [1].

  local B = require 'baz'
  local V = require 'verlib'
  if V(B._VERSION) >= V'1.2.5' then
       -- as opposed to just `B._VERSION >= '001.002.005'`
   . . .
  else
    . . .
  end

Implementing verlib in Lua would also be a valid approach though.
Should we bother?  With git, we just accept unfriendly version numbers
(e.g. 8d1985807b).

[1] http://www.python.org/dev/peps/pep-0386/

Reply | Threaded
Open this post in threaded view
|

Re: module _VERSION number scheme proposal

Miles Bader-2
David Manura <[hidden email]> writes:

> It is a trade-off.  The main intention of the zero padding is to allow
> versions to be compared by simple string comparison, i.e. without any
> external version library like verlib [1].
>
>   local B = require 'baz'
>   local V = require 'verlib'
>   if V(B._VERSION) >= V'1.2.5' then
>        -- as opposed to just `B._VERSION >= '001.002.005'`
>    . . .
>   else
>     . . .
>   end
>
> Implementing verlib in Lua would also be a valid approach though.
> Should we bother?  With git, we just accept unfriendly version numbers
> (e.g. 8d1985807b).

I think a simple "version_compare" function (version_greater, whatever)
would be more straight-forward; indeed, something like that already
exists in GNU libc -- strverscmp.  The basic idea is:  compare
lexigraphically, but compare any embedded integers as numbers.

-Miles

--
Friendship, n. A ship big enough to carry two in fair weather, but only one
in foul.

Reply | Threaded
Open this post in threaded view
|

Re: module _VERSION number scheme proposal

Rena
On Tue, Nov 8, 2011 at 21:19, Miles Bader <[hidden email]> wrote:

> David Manura <[hidden email]> writes:
>> It is a trade-off.  The main intention of the zero padding is to allow
>> versions to be compared by simple string comparison, i.e. without any
>> external version library like verlib [1].
>>
>>   local B = require 'baz'
>>   local V = require 'verlib'
>>   if V(B._VERSION) >= V'1.2.5' then
>>        -- as opposed to just `B._VERSION >= '001.002.005'`
>>    . . .
>>   else
>>     . . .
>>   end
>>
>> Implementing verlib in Lua would also be a valid approach though.
>> Should we bother?  With git, we just accept unfriendly version numbers
>> (e.g. 8d1985807b).
>
> I think a simple "version_compare" function (version_greater, whatever)
> would be more straight-forward; indeed, something like that already
> exists in GNU libc -- strverscmp.  The basic idea is:  compare
> lexigraphically, but compare any embedded integers as numbers.
>
> -Miles
>
> --
> Friendship, n. A ship big enough to carry two in fair weather, but only one
> in foul.
>
>

Isn't that generally called natural compare? It's used by smart file
browsers too so that file10.jpg doesn't list before file2.jpg.

--
Sent from my toaster.

Reply | Threaded
Open this post in threaded view
|

Re: module _VERSION number scheme proposal

David Manura
On Tue, Nov 8, 2011 at 11:35 PM, HyperHacker <[hidden email]> wrote:
> On Tue, Nov 8, 2011 at 21:19, Miles Bader <[hidden email]> wrote:
>> I think a simple "version_compare" function (version_greater, whatever)
>> would be more straight-forward; indeed, something like that already
>> exists in GNU libc -- strverscmp.  The basic idea is:  compare
>> lexigraphically, but compare any embedded integers as numbers.
> Isn't that generally called natural compare? It's used by smart file
> browsers too so that file10.jpg doesn't list before file2.jpg.

Looks so [1].  If the comparison function we use for _VERSION is also
useful for natural order comparisons in general, that would be a plus.

One thing this will not always handle, unlike that Python scheme [2],
is pre-release tags [3] like '5.2.0-beta1 < 5.2.0'.  Personally, I've
been moving away from using those to instead putting the stability
level *after* the version: '5.2.0.5 > 5.2.0.4rc > 5.2.0.3b > 5.2.0.2b
> 5.2.0.1a'.  This keeps version comparisons simpler (and also allows
reverting back to beta, 5.2.0.6b, if need be).

[1] http://www.codinghorror.com/blog/2007/12/sorting-for-humans-natural-sort-order.html
.
[2] http://www.python.org/dev/peps/pep-0386/
[3] http://en.wikipedia.org/wiki/Software_versioning#Pre-release_versions

Reply | Threaded
Open this post in threaded view
|

Re: module _VERSION number scheme proposal

Tony Finch
In reply to this post by David Manura
David Manura <[hidden email]> wrote:
>
> With git, we just accept unfriendly version numbers (e.g. 8d1985807b).

Developers do, but for users it is better to use the output of `git
describe`, e.g. unifdef-2.6-6-g8ab6d1a-dirty (which is six revisions
after the unifdef-2.6 tag and the working tree has been modified).

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
German Bight: South or southeast 4 or 5. Slight or moderate. Occasional
drizzle, fog patches. Moderate, occasionally very poor.

Reply | Threaded
Open this post in threaded view
|

Re: module _VERSION number scheme proposal

Michael Richter
I'm finding all this string- and float-fetish here a bit odd.  Is there some reason we can't just have version tables like this:



--
"Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
Reply | Threaded
Open this post in threaded view
|

Re: module _VERSION number scheme proposal

Michael Richter
D'oh!  Sorry.  Hit "send" by accident.

On 10 November 2011 15:06, Michael Richter <[hidden email]> wrote:
I'm finding all this string- and float-fetish here a bit odd.  Is there some reason we can't just have version tables like this:

M1._version = { 1, 2, 3 }   // equivalent to version 1.2.3
M2._version = { 4, 5 }      // equivalent to version 4.5
M3._version = { 3, 1, 4, 1, 5, 9, 2, 6, 5, 3, 5, 8, 9, 8 }
                            // equivalent to version dotted-pi

We could then have a standard module version metatable (initially a de facto standard, but later perhaps even officially blessed) that provides natural comparison semantics (so that 4.5 is greater than 1.2.3, for example), that provides a default printing format, both long-form and short-form even if you'd like and provides other versioning services.

--
"Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
Reply | Threaded
Open this post in threaded view
|

Re: module _VERSION number scheme proposal

David Hollander
If the present goal is "unique id", instead of:
(file name, version protocol) --> unique id

why not just do:
(file name, sha2 hash of content) --> unique id

A protocol for versions is itself subject to versions, whereas a SHA2
hash is not.

- David

On Thu, Nov 10, 2011 at 1:12 AM, Michael Richter <[hidden email]> wrote:

> D'oh!  Sorry.  Hit "send" by accident.
>
> On 10 November 2011 15:06, Michael Richter <[hidden email]> wrote:
>>
>> I'm finding all this string- and float-fetish here a bit odd.  Is there
>> some reason we can't just have version tables like this:
>
> M1._version = { 1, 2, 3 }   // equivalent to version 1.2.3
> M2._version = { 4, 5 }      // equivalent to version 4.5
> M3._version = { 3, 1, 4, 1, 5, 9, 2, 6, 5, 3, 5, 8, 9, 8 }
>                             // equivalent to version dotted-pi
>
> We could then have a standard module version metatable (initially a de facto
> standard, but later perhaps even officially blessed) that provides natural
> comparison semantics (so that 4.5 is greater than 1.2.3, for example), that
> provides a default printing format, both long-form and short-form even if
> you'd like and provides other versioning services.
> --
> "Perhaps people don't believe this, but throughout all of the discussions of
> entering China our focus has really been what's best for the Chinese people.
> It's not been about our revenue or profit or whatnot."
> --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
>

Reply | Threaded
Open this post in threaded view
|

Re: module _VERSION number scheme proposal

Rena
On Thu, Nov 10, 2011 at 01:44, David Hollander <[hidden email]> wrote:

> If the present goal is "unique id", instead of:
> (file name, version protocol) --> unique id
>
> why not just do:
> (file name, sha2 hash of content) --> unique id
>
> A protocol for versions is itself subject to versions, whereas a SHA2
> hash is not.
>
> - David
>
> On Thu, Nov 10, 2011 at 1:12 AM, Michael Richter <[hidden email]> wrote:
>> D'oh!  Sorry.  Hit "send" by accident.
>>
>> On 10 November 2011 15:06, Michael Richter <[hidden email]> wrote:
>>>
>>> I'm finding all this string- and float-fetish here a bit odd.  Is there
>>> some reason we can't just have version tables like this:
>>
>> M1._version = { 1, 2, 3 }   // equivalent to version 1.2.3
>> M2._version = { 4, 5 }      // equivalent to version 4.5
>> M3._version = { 3, 1, 4, 1, 5, 9, 2, 6, 5, 3, 5, 8, 9, 8 }
>>                             // equivalent to version dotted-pi
>>
>> We could then have a standard module version metatable (initially a de facto
>> standard, but later perhaps even officially blessed) that provides natural
>> comparison semantics (so that 4.5 is greater than 1.2.3, for example), that
>> provides a default printing format, both long-form and short-form even if
>> you'd like and provides other versioning services.
>> --
>> "Perhaps people don't believe this, but throughout all of the discussions of
>> entering China our focus has really been what's best for the Chinese people.
>> It's not been about our revenue or profit or whatnot."
>> --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
>>
>
>

Tables and hashes aren't easily comparable.

--
Sent from my toaster.

Reply | Threaded
Open this post in threaded view
|

Re: module _VERSION number scheme proposal

Michael Richter
On 10 November 2011 16:45, HyperHacker <[hidden email]> wrote:
Tables and hashes aren't easily comparable.

They are if you provide the metatable with comparison operators.  That was sort of my point.

--
"Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
Reply | Threaded
Open this post in threaded view
|

Re: module _VERSION number scheme proposal

Duncan Cross
On Thu, Nov 10, 2011 at 9:34 AM, Michael Richter <[hidden email]> wrote:
> On 10 November 2011 16:45, HyperHacker <[hidden email]> wrote:
>> Tables and hashes aren't easily comparable.
> They are if you provide the metatable with comparison operators.

The comparison metamethods are only consulted if both values are of
the same basic type, so even with those you cannot make a table == a
string.

-Duncan

Reply | Threaded
Open this post in threaded view
|

Re: module _VERSION number scheme proposal

David Hollander
In reply to this post by Rena
> Tables and hashes aren't easily comparable.
Whether you are implementing a package distribution service, or just
loading a file as a client, you will have read access to the file
contents anyway. A string equality comparison of a hexadecimal hash is
the most deterministic way to assert identity, and pure Lua hashing
implementations are available.[1] In vivo, self reported version
numbers tend to merely be additional non-determinstic "description"
bits.[2]
If the problem is not one of uniqueness, but of temporal sequencing,
my second suggestion is to use a "os.time()" timestamp property. If
the actual property one desires to compare is comparable, then
bikeshedding over meta-information can be avoided.

[1] http://lua-users.org/wiki/SecureHashAlgorithm
[2] https://lkml.org/lkml/2011/5/29/204
On Thu, Nov 10, 2011 at 2:45 AM, HyperHacker <[hidden email]> wrote:

> On Thu, Nov 10, 2011 at 01:44, David Hollander <[hidden email]> wrote:
>> If the present goal is "unique id", instead of:
>> (file name, version protocol) --> unique id
>>
>> why not just do:
>> (file name, sha2 hash of content) --> unique id
>>
>> A protocol for versions is itself subject to versions, whereas a SHA2
>> hash is not.
>>
>> - David
>>
>> On Thu, Nov 10, 2011 at 1:12 AM, Michael Richter <[hidden email]> wrote:
>>> D'oh!  Sorry.  Hit "send" by accident.
>>>
>>> On 10 November 2011 15:06, Michael Richter <[hidden email]> wrote:
>>>>
>>>> I'm finding all this string- and float-fetish here a bit odd.  Is there
>>>> some reason we can't just have version tables like this:
>>>
>>> M1._version = { 1, 2, 3 }   // equivalent to version 1.2.3
>>> M2._version = { 4, 5 }      // equivalent to version 4.5
>>> M3._version = { 3, 1, 4, 1, 5, 9, 2, 6, 5, 3, 5, 8, 9, 8 }
>>>                             // equivalent to version dotted-pi
>>>
>>> We could then have a standard module version metatable (initially a de facto
>>> standard, but later perhaps even officially blessed) that provides natural
>>> comparison semantics (so that 4.5 is greater than 1.2.3, for example), that
>>> provides a default printing format, both long-form and short-form even if
>>> you'd like and provides other versioning services.
>>> --
>>> "Perhaps people don't believe this, but throughout all of the discussions of
>>> entering China our focus has really been what's best for the Chinese people.
>>> It's not been about our revenue or profit or whatnot."
>>> --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
>>>
>>
>>
>
> Tables and hashes aren't easily comparable.
>
> --
> Sent from my toaster.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: module _VERSION number scheme proposal

Michael Richter
In reply to this post by Duncan Cross
On 10 November 2011 18:02, Duncan Cross <[hidden email]> wrote:
>> Tables and hashes aren't easily comparable.
> They are if you provide the metatable with comparison operators.

The comparison metamethods are only consulted if both values are of
the same basic type, so even with those you cannot make a table == a
string.

And we're back to the string fetish. Why would I want to compare a table to a string if I've got the tables?  (And, of course, if I absolutely must compare to a string, surely a function to convert from the table to the string could be added…)

--
"Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
Reply | Threaded
Open this post in threaded view
|

Re: module _VERSION number scheme proposal

David Hollander
> 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


On Thu, Nov 10, 2011 at 4:32 AM, Michael Richter <[hidden email]> wrote:

> On 10 November 2011 18:02, Duncan Cross <[hidden email]> wrote:
>>
>> >> Tables and hashes aren't easily comparable.
>> > They are if you provide the metatable with comparison operators.
>>
>> The comparison metamethods are only consulted if both values are of
>> the same basic type, so even with those you cannot make a table == a
>> string.
>
> And we're back to the string fetish. Why would I want to compare a table to
> a string if I've got the tables?  (And, of course, if I absolutely
> must compare to a string, surely a function to convert from the table to the
> string could be added…)
> --
> "Perhaps people don't believe this, but throughout all of the discussions of
> entering China our focus has really been what's best for the Chinese people.
> It's not been about our revenue or profit or whatnot."
> --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
>

Reply | Threaded
Open this post in threaded view
|

Re: module _VERSION number scheme proposal

Thomas Harning Jr.
On Thu, Nov 10, 2011 at 2:05 PM, David Hollander <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: module _VERSION number scheme proposal

David Hollander
> 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. <[hidden email]> wrote:

> On Thu, Nov 10, 2011 at 2:05 PM, David Hollander <[hidden email]> 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.
>
>

12