Email list hosting service & mailing list manager

Keeping the version in filenames Göran Weinholt (01 Oct 2009 16:29 UTC)
Re: Keeping the version in filenames Abdulaziz Ghuloum (02 Oct 2009 05:53 UTC)
Re: Keeping the version in filenames Göran Weinholt (02 Oct 2009 12:59 UTC)
Re: Keeping the version in filenames Derick Eddington (02 Oct 2009 16:22 UTC)
Re: Keeping the version in filenames Abdulaziz Ghuloum (02 Oct 2009 17:24 UTC)
Re: Keeping the version in filenames Derick Eddington (02 Oct 2009 20:13 UTC)
Re: Keeping the version in filenames Abdulaziz Ghuloum (02 Oct 2009 16:51 UTC)
Re: Keeping the version in filenames Derick Eddington (02 Oct 2009 20:25 UTC)
Re: Keeping the version in filenames Derick Eddington (02 Oct 2009 13:06 UTC)
Re: Keeping the version in filenames Abdulaziz Ghuloum (02 Oct 2009 16:26 UTC)
Bye-bye versioning Derick Eddington (02 Oct 2009 19:56 UTC)

Re: Keeping the version in filenames Abdulaziz Ghuloum 02 Oct 2009 17:23 UTC

On Oct 2, 2009, at 7:22 PM, Derick Eddington wrote:

>> If a library
>> developer wants to do that, he can simply append a major version to
>> the
>> end of a library identifier, something like this:
>>
>> (foo jpeg (0))   foo/jpeg.sls   initial version (0 is the minor)
>> (foo jpeg (1))   foo/jpeg.sls   second version, supports more formats
>> (foo jpeg1 (0))  foo/jpeg1.sls  third version with a much better API
>>
>> If he wants to he can even make it so (foo jpeg) is a compatibility
>> wrapper around (foo jpeg1). Such a wrapper would be very useful for
>> anyone changing a program to use the new library, because it would
>> show
>> exactly what changes are necessary. And if the developer was careful,
>> there will not be any point in keeping (foo jpeg (0)) around when
>> you've
>> got (foo jpeg (1)).
>>
>> This is much less tedious than requiring that every part of a version
>> reference always must be included in the filename, and it leaves the
>> individual developer free to choose what he and his users need.
>
> Problems with this scheme are: semantic disintegration between major
> numbers and minor numbers, version constraints cannot be used on major
> numbers, and an additional redundant versioning convention to deal
> with.

It's not redundant; it's just different.  Versions as part of the
library name allows for two different libraries to exist at the
same time (at the Scheme level and at the file system level).
Whether that's desirable or not depends on the specific library.

Libraries with different R6RS versions (separate from file names)
cannot coexist at both the Scheme level or the file system level.
Again, whether that's desirable or not depends on the specific
library.

Libraries with different R6RS versions (named according to this
SRFI) can coexist at the file system level but cannot coexist
at the Scheme level.  Furthermore, which combinations of them
actually work together, and which combination will be picked by
the implementation are both unspecified.

So, I'm now totally confused about what the real problem that
you're trying to solve.

> I think putting any part of the version in the last symbol (or any
> symbol) is going against the purpose of compound library names.

I disagree.  I did object to the final draft of R6RS when it
renamed the libraries from (r6rs *) to (rnrs * (6)) and I did
list the reasons for why, but no one listened.  I'm too lazy
to look it up now.

Aziz,,,