Although I object to some of your characterizations of the difference
between PLaneT and the new package system, it's fair to say that PLaneT
provides better support to package authors for creating new APIs that
are intended to replace (but coexist with) old APIs.
I think the answer to that problem in the new system is better tools
for package authors, along with better catalog-display mechanisms for
package users. That is, I think "javascript" through "javascript9" are
fine as package names (and even collection names), but I think those
packages should be grouped together as a listing in the catalog.
Meanwhile, we need tools to help the author of "javascript3" introduce
"javascript4", and so on.
Creating an external tool might not be necessary if the notion of
major-version-compatibility were built into the package system in a
different way. Unfortunately, it's not easy to add more version support
into the current design and implementation. It's the same as designing
a more traditional programming language: choices interact with all
sorts of trade-offs, both conceptually and in the implementation.
So, if the question is "will the core package system's treatment of
versions change?", then I think the answer is "no". If the question is
"will the package versioning experience improve for package authors and
users?", then I hope the answer is "yes" --- but I intend to leave the
actual answer to others (yes, you!), for now. Until we find otherwise,
I can't help feeling that the current design and implementation has all
the primitives that we need[*] for building better things on top.
[*] Of course, it has way too many primitives. Again, like any design,
it's a process to figure out what the true core could be.
At Sun, 30 Nov 2014 10:43:19 -0500, Neil Van Dyke wrote:
> 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
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
