Any chance of revisiting the new package system's stances on versions --
specifically, on the two issues:
1. Can subsequent versions of a named package (which has an identity)
be non-backward-compatible?
2. Can a Racket setup (and even an individual program) have multiple
versions of a package at the same time?
Regarding #1, the requirement to never make a non-backward-compatible
version of a package without giving up package identity is a burden, and
a deterrent to third-party package releases.
For a real-world example, see "http://planet.racket-lang.org/";, where it
looks like most of the familiar names (who were going to a good amount
of trouble to release already), managed to release packages marked as
non-backward-compatible (i.e., PLaneT major version number other than
1). Wouldn't requiring them to never break backward compatibility be a
deterrent to releasing at all? Or, if they still released, would
`dherman`, following the instructions of Racket to create a new package
identity for any backward-incompatible version, have given us packages
`javascript`, `javascript2`, ... `javascript9`, rather than `javascript`
versions `1.x` through `9.x`.
No-backward-incompatibility might make sense for core Racket (although
even core Racket has broken this multiple times), but it's a big
deterrent to researchers, and to industry developers who are willing to
open source components of their larger systems in lightweight ways.
Regarding #2, I suggest that should be revisited if #1 is revisited.
I think PLaneT got both of these a lot closer to right, at least for
third-party packages.
Neil V.
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
