[racket-dev] planet2 and versions

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 <ryan at 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>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20121212/9ac56213/attachment.html>