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