FWIW, there has been much discussion about these in the context of
Perl's CPAN and Ruby's GEMs. They have generally settled on a
versioning Scheme like the one we adopted for PLaneT (unlike PLaneT,
however, theirs are a kind of "best practice" rather than encouraged or
enforced by the system).
PLaneT's versioning Scheme is written up in this year's Scheme workshop:
http://scheme2006.cs.uchicago.edu/04-matthews.pdf
The short version: too many do-dads isn't a good idea, but a major and
minor version numbers are. The minor version number changes when the
producer just means to have a backwards compatible update, and the
major version changes when the producer is making a non-backwards
compatible update.
In any case, I think we'd benefit a lot from their experience.
Robby
At Fri, 10 Nov 2006 17:08:46 -0500, MichaelL_at_frogware.com wrote:
> > The situation changes with multiple developers or with libraries pulled
> > from central code repositories (like PLT's planet, Perl's CPAN, Chicken
> > Eggs, Ruby Gems, ...). In these situations, it is better to have a
> > single agreed-upon versioning scheme to specify exactly what the import
> > requirements for a library are. You want to be able to look at a
> > library and figure out exactly what it needs rather than attempt to
> > guess what versioning scheme was used.
>
> Thanks; that's interesting. I'd like to think about it more. (Basically
> what I hear you saying is that whether or not it's useful *inside* Scheme
> it's potentially useful *outside* Scheme. I hadn't thought of that.)
>
> > Moreover, it gives you the
> > option of upgrading a library (using minor versions) without having to
> > go through every single file in your system (or in the world) to rename
> > the imported library names.
>
> Imagine that there's a regexp library, and imagine that we were using v3.2
> and now v3.3 has come along. If the library was originally called
> regexp-3.2 I agree that we'd now have to visit all libraries to change
> regexp-3.2 to regexp-3.3. So far so good. I disagree, however, that
> separate version numbers would really help--at least, not in the way you
> think they would.
>
> With the current syntax, you could import the regexp library with one of
> the following:
>
> 1. regexp
> 2. (regexp (3))
> 3. (regexp (3 2))
> 4. (regexp (3 2 5))
>
> It's true that if you used option 1 or 2 you wouldn't have to change any
> imports. At the same time, it's true that you've just shifted the risk
> elsewhere--the risk that the new v3.3 libraries are compatible with v3.2.
> It's possible that v3.3 changed its interface, in which case you'll get a
> compile-time error, and it's possible that v3.3 changed its contract, in
> which case you'll get a run-time error. If you don't want that kind of
> risk you'll have to use option 3--and you're back to where we started
> from. When v3.3 comes out you'll have to visit the libraries that used
> v3.2 to see if they're safe to switch to the latest version, and if so
> you'll have to note that in the import specification.
>
> To my mind option 4 is potentially interesting. There it might be possible
> to express "I want a 3.2 library that's greater or equal to 3.2.5." (I
> don't see a way to do that with the current syntax because I can't say
> "less than 3.3" only "less than or equal to 3.3".) If everyone everywhere
> agrees that the third number changes only when there are bug fixes (and no
> interface or contract changes) then that might be a way to verify that you
> link with a library that fixes some known defects while still accepting
> any newer library that honors the intended constraints. But that's a
> relatively narrow benefit I think, and I just don't know that it would see
> much use in practice.
>
> (Btw, maybe the fourth option is what you meant by "minor version." If so,
> my apologies. I always think of the second number as "minor" and the third
> number as "patch", and in my book only patch levels give you strong
> compatibility guarantees.)
>
> I should point out that I *can* think of ways to make all of this much
> more useful, but I think that those ideas are currently out of scope for
> R6RS. For example, if you could test for the *presence* of a library at
> compile-time you could use that information in a cond-expand or some such
> thing to make interesting compile-time (and run-time) decisions. For
> instance, you might choose to implement regexp in terms of the
> Perl-compatible regexp library if it's availble, and in terms of the
> Scheme portable regexp library if it isn't. Likewise, if you had access to
> a library's version number you might use it at compile time to provide
> work-arounds for known bugs in specific versions or you might use it at
> run-time to provide a diagnostic list of what versions of what libraries
> were included in a particular app. To me that kind of thing makes version
> numbers much more useful from within Scheme, but I just can't imagine the
> editors considering such things at this point.
>
> > Now regarding the library names being a single identifier vs. a list, I
> > agree that a single identifier is simpler and there is no need as of
> > right now for composite names. A naming convention might be needed
> > though in order to disambiguate the different parts. For example, Perl
> > (and others perhaps) uses :: as a name separator. A dash may not be
> > ideal since it is used extensively in identifier names (for example,
> > r6rs-hash-tables does not imply that there might be r6rs-hash-trees.
> > r6rs::hash-tables or r6rs/hash-tables do a better job separating the
> > names).
>
> Yes, I think there are a few places in R6RS where new naming conventions
> might be useful, and I agree that this might be one of them.
>
> Thanks for your feedback. Very helpful.
>
> _______________________________________________
> r6rs-discuss mailing list
> r6rs-discuss_at_lists.r6rs.org
> http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Received on Fri Nov 10 2006 - 17:21:17 UTC