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. Carl Eastlund On Wed, Dec 12, 2012 at 2:29 PM, Ryan Culpepper <r...@cs.utah.edu> wrote: > 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: > http://lists.racket-lang.org/**dev <http://lists.racket-lang.org/dev> > >
_________________________ Racket Developers list: http://lists.racket-lang.org/dev