From: Ben Tilly <ben_tilly@...>
Date: 2001-01-07T07:44:06+09:00
Subject: [ruby-talk:8769] Re: Visions for 2001/1.7.x development?

Charles Hixson <charleshixsn@earthlink.net> 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.
>
>This is a very good idea, if possible.  I would encourage the allowing
>of fairly complex expressions for the version calculation, and that
>versions be specified by a string rather than a float.  Then this would
>suggest that pattern matching for the version specification.  Of course
>a complex boolean would be easier to understand {ver >= "1.6" && ver !=
>"1.6.3b" && ver < "2."} and a function would be more flexible...

While I understand the desire for flexibility, flexibility when
it comes to version control leads to pain IMO.

Here is a fairly sophisticated proposal.

They are widely enough used that version tuples make sense:

  major.minor.rev

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.

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.

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.

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

>(The boolean would likely be a good idea.  I don't think that the
>function would be.)
>
Cheers,
Ben
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com