I believe it is by design that Planet 2 does not resolve this kind of issue. This gives us room to experiment with different solutions without committing to one up-front, since Planet 1 ran into various limitations of its built-in policies. I will propose one possible solution for your "webapis" example. Distribute a primary wrapper package called "webapis" and separate specific versions such as "webapis1", "webapis2", and so forth. Have the code in "webapis" determine at compile-time which specific version of webapis is appropriate for the current Racket version and install that package. The specific packages would contain the actual code a client would import. That way, installing the "webapis" package on any Racket version would install only the version of the implementation that works. I don't know if this is a complete solution, but it seems like a reasonable starting point. As we figure out what patterns work, they themselves can be developed as reusable tools and built into their own packages. I think this room for improvement will make Planet 2 a much better long-term model than Planet 1. Of course we do eventually want a default system that package developers can use without too much mucking about with "experimental" versioning systems. But I think an initial period of "crowd-sourcing" the design of that system will do us some good. <div class="gmail_extra"> <div>Carl Eastlund</div> <div class="gmail_quote">On Wed, Dec 12, 2012 at 2:29 PM, Ryan Culpepper <<a href="mailto:ryan@cs.utah.edu" target="_blank">ryan@cs.utah.edu</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I'm trying to understand how things are supposed to work in planet2 without version information. Let's say I release a package, "webapis". Time passes, and I notice that Racket gets some cool new features (eg, better SSL support) that the "webapis" package should use. I write the code, and ... Do I release the new code under the same package name? If so, then the package breaks for older versions of Racket, because IIUC planet2 has nothing corresponding to planet1's 'required-core-version field. And there doesn't seem to be a way to tell Racket "no, sorry, go back to the older version of the package". (Rather, there's no way for a client to do so. The fix would be for the package maintainer to release an "upgrade" that reverts to the old code.) So it seems like it would be really bad for me to release the new code under the name "webapis". In other words, if a package changes its dependencies, that's an incompatible change for the package, and it needs a new name. Right? Suppose I release the new code as "webapis2". And suppose there's another package (let's call it "scriblogify") that depends on "webapis". If that code wants to use "webapis2", that's a dependency change, so it would have to be released as "scriblogify2". There's no way to express "link me with the most recent compatible version of webapis*", right? Ryan _________________________ Racket Developers list: <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a> </blockquote></div> </div>