[ruby-talk:8888] Re: Visions for 2001/1.7.x development?

Ben Tilly wrote:

> Charles Hixson <[e-mail]> wrote:
> 
>> 
>> Yukihiro Matsumoto wrote:
>> 
>>> Hi,
>>> ...
>>> 
>>> |* Ruby-enforced (or at least supported) way to versioning of
>>> |  scripts/extensions. Can be used both from Ruby code ("require
>>> |  'BitVector' {VERSION >= 1.6}") and from RAA-installer ("raa-get
>>> |  Bitvector 1.6.1"). Different versions can co-exist on my Ruby set-up.
>>> 
>>> I like the basic idea.  But I still don't have concrete strategy to
>>> make it possible.
>>> ...
>>>                             matz.
>> 
>> 
... 
> They are widely enough used that version tuples make sense:
> 
>  major.minor.rev
I agree with the major.minor.rev
  version number, but that looks like a string to me 
more than like a number.

> 
> Any major rethinking of structure results in incrementing
> major, and two versions of the same libary that have a
> different major version are not expected to be compatible.
> New features can be added in a minor version, but would
> generally be assumed upwards (though not downwards)
> compatible.  Revs are bug-fixes, pure and simple.

OK.  So I guess that this says that the require'd 
file shouldn't depend on which revision number is 
used.  If this is a save assumption (which I find 
questionable, but possible) then a simple integer 
could be used for the version (= major.minor * 100). 
  But I'm not sure that this really simplifies 
things.  And it makes it more difficult to separate 
version numbers by differences between their file 
names (which I was considering).

> 
> The lookup system should not worry about having things
> that use different revs.  It should allow you to specify
> minimum version (with the rev possibly significant).
> A maximum version (major.minor only) could also be
> though it shouldn't be assumed to work.  In general it
> would be unwise to assume compatibility on a major version
> unless the software specifically said otherwise.  It
> should by default use the version that does not have a
> version name in it, and failing that use the highest
> compatible version
The problem here is if one needs to disallow certain 
specific versions.  This is a hopefully rare 
occurance, but I have experienced it in the past 
(usually with compilers, but I don't know that 
libraries would be an exception).

> 
> Any script that wound up loading things that want to use
> multiple versions of the same library should be registered
> as having an internal conflict.
The problem is not with wanting to use multiple 
versions of the same library, as with specifically 
NOT wanting to use some particular version (perhaps 
it just happens to break some small feature that you 
depend on, and this was working in both the prior 
and the succeeding versions).

> 
>> One thing that this would require is a method for keeping several
>> different versions of the same code around, probably by requiring
>> something like the filename to be embedded in the second line of the
>> file (not the first line, as that would interfere with the #!/usr/...
>> convention).
> 
> How would I keep two versions of a library in parallel?
> 
> Yes, let the code say its version.  But also let the lookup
> for a library search with the version in its name.  Now add
> in a standard naming scheme (Debian does this).
> 
> In my proposal it would be sufficient to have major.minor
> in the names.  Loading specific versions like this would
> involve searching the directory, and might be slow.  (Which
> is why in my proposal I went for the default version first.)
I can accept the major.minor (though I do think that 
minor bugs might only show up in one revision).  I 
don't see that searching the directory this way 
would be any slower than searching the directory 
anyway.  And usually one probably wouldn't specify 
the version (which would mean take the highest 
version available).

On second reading it seems like you might be talking 
about C modules.  (Though I'm having enough trouble 
trying to load the gtk module that I may just 
misunderstand the whole process.)  I have been 
assuming that the search process involved searching 
through PATH, not that it involved an internal 
table.  But if the internal table were Ruby code, 
then I can see a possible problem My first thought 
was that the reasonable approach would seem to be an 
avl tree as a hash wouldn't search in any reasonable 
order, but on second thought a hash on the name that 
lead to a list sorted by version key (highest first) 
would seem to solve the problem in short order.

> ...
> Cheers,
> Ben
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com