AndrevanTonder wrote: > I'm not sure I understand the issue you mention. With my simple suggestion, > a > client import of 6.2 will match the bug-fixed 6.2.1, and import the latter, > as > desired. >
That concept is messed up. It assumes that the question "should 6.2.1 be used instead of 6.2?" has the same answer for all applications that happened to allow both version numbers in their imports. The problem is that the question can easily have multiple answers. Perhaps 6.2.1 fixes a bug which is critical to, say, the web server -- but the same bug fix accidentally breaks the printer driver, for which the bug fix wasn't even needed in the first place. What then? The decision "is library version X suitable and preferable for the import in library Y?" should be a late bound decision. That is, it should not be a static property of the source texts of X and Y but, instead, should be determined outside of X and Y, at run-time -- essentially by a separate program. Version numbers aren't needed at all, except for human consumption (hints, nothing more). What is needed is a way to configure linkages separately from programs. Whatever that configuration mechanism should be, its design should make it practical to manage the linkage of many programs at once with just a few changes, and also make it practical to manage the linkage of any one program, in detail, regardless of what's happening to other programs. Installing a new version of a library should never change the meaning of existing programs. Modifying the linkage specification of a program or programs should change their meaning. No need for version numbers at all. -t _______________________________________________ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
