From: Michael Sperber <[EMAIL PROTECTED]> Subject: Re: [r6rs-discuss] [Formal] Version reference syntax is overly complex. Date: Thu, 21 Jun 2007 13:36:23 +0200
> As much as I'd like this, my experience with Python, Perl and the like, > and the design of the library system make me hesitate: The problem is > that one person's compatible upgrade is another person's incompatible > change. Ideally, we'd have only three components to each version > number: major, minor, and "patch level". The patch level gets bumped > when bugs get fixed, minor gets bumped when things are added to the > interface, and major gets bumped when incompatible changes are made. > > In the real world, I've often seen people work around bugs, effectively > producing code that depends on their specific nature. (I know they > shouldn't, relying only on the interface. We don't even have a serious > notion of "interface".) Fixing the bug breaks their code. So, > patch-level changes are really often incompatible changes. Minor gets > bumped when old keywords acquire new syntatic cases---that's OK, I > think. It also gets bumped when old procedures work on more inputs than > before. Mostly OK, but can cause problems when clients rely on > exceptions for these cases. Minor also gets bumped when new exports are > added, which may clash with other libraries. Bad. An excellent summary, and this is exactly why I think r5.94rs version reference won't work well. Even library foo releases version 2.3.1 that fixes number of bugs in 2.3, you cannot expect everyone to upgrade to foo-2.3.1 immediately; sometimes it take months or even a few years until migration is done, especially when lots of code depends on foo. If your library breaks because of the subtle incompatibility between foo-2.3 and foo-2.3.1, how you want to maintain your library? You may release both yourlib-1.3 which requires foo-2.3 and yourlib-1.3.1 which requires foo-2.3.1 and let people choose. But you will probably make more releases of yourlib, while the world is still using both foo-2.3 and foo-2.3.1. Argh. You may make branches, yourlib-1.3.0.x series for foo-2.3 and yourlib-1.3.1.x series for foo-2.3.1. Then, what if another library bar, which yourlib depends, also releases an incompatible new version? I think complex version reference spec won't solve this problem. At some point you have to put conditional in your library based on the API version you're depending. Andre's suggestion #3 (requiring minimum version) is a nice compromise. Even in the above scenario, you can still declare that you won't support anything before foo-2.3. And you support both foo-2.3 and foo-2.3.1 by switching your code depending on its version. Though I still think version reference is not essential at all, when we have means to switch code depending of the library, and minimum version requirements can be checked by existing package management tools. --shiro _______________________________________________ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
