[ruby-talk:15443] Re: An Attempt at Versioning

Replying to all of you at once:


On Tue, 8 May 2001, Dave Thomas wrote:
> Mathieu Bouchard <[e-mail]> writes:
> > The requiring file does this kind of thing:
> > 	require("SomeFile") {|v| v >= [2,3] && v < [2,4] }
> > and the required file does this kind of thing:
> > 	require "Version"; version_is 5,1
> How about extending the idea slightly, and at the same time making it
> slightly more general:
>  somefile.rb:
>     VersionInfo {
>       version 1.2.3
>       author  "matju"
>       ... etc
>     }

Now that I think of it, I think the versioning better applies to whole
packages, which consist of several files. Each package would have a source
file representing that package (a "version file"), which would not require
anything else than plain Ruby; that way, RAA.succ would be able to gather
info about a package without having to parse any file other than by
loading it through the Ruby parser. All other source files in the package
would require that version file. 

A versioned "require" would not ask the required file for version info,
but somehow should ask the version file of the required file.

The version file would be quite like the version block you are suggesting.



On Fri, 11 May 2001, Sean Russell wrote:
> What do you think about a version which allows for intelligent loading,
> so that multiple versions of a module/library can exist on a platform
> at once?
> For example:
> [...]
> Where getAllVersions finds all files in the search path by the name
> #{file}(_(\d+(\.\d+)*))?\.rb, in order of the version numers.  Ergo,
> we'll always get the newest compatible version of the library.

This is a good idea; not sure how the particular implementation
should work though: may involve one directory per package, if we don't
want renaming files... However, a program that (indirectly) require
several different versions of the same file or package would still not
work, but I'm not sure something can be done about it.



On Fri, 11 May 2001, Colin Steele wrote:
> * maintaining multiple compatible versions of a library on a system
> * maintaining multiple INcompatible versions of a library on a system

Those are worthy goals

> * creating impenetrable separation between interface and implementation

I'm not sure what do you mean by "impenetrable".

I suppose we could (and should) have a separate version system for
"compatibility", that is, a version system for "interface"; the other
(regular) version system would be for implementation; however the kind of
problem that crops up here is... bugs. Implementations have bugs, that is,
failure to comply with a certain interface. I'm not sure what (and whether
anything) should be done to handle bugs and bugfixes in relationship to
this. 

> Thankfully, some of the traditional problems are ones we don't have to
> deal with (yet?):
>       * code incompatibility at the binary level
> One might argue that some of these issues aren't applicable to Ruby.
> (For instance, binary compatibility.)  That's an open debate I think
> we should have.

Binary compatibility is applicable to Ruby in the measure that the Ruby
interpreter is written in C and the extension API to Ruby is designed for
C and all it implies. All packages that contain .so/.dll files are
potentially affected.

> However, I hope we don't lose sight of the fact that a) overall,
> library versioning is a critical need, and b) there are historical
> attempts to solve this problem in other contexts that may provide
> valuable lessons for us.

May you provide more (historical) background on versioning with separation
of interface and implementation?

matju