On 12/12/2012 03:58 PM, Jay McCarthy wrote:
I agree with Carl.
But I would make an even stronger suggestion, I would suggest that you
completely drop support for old Racket versions and if necessary
release "webapis-lts" and "scriblogify-lts" packages that conflict
with "webapis" and can only work on old versions. The LTS ones
wouldn't be included in the DrDr-tested collection of packages, but
the others would be. Casual users should upgrade and users with
serious version problems should upgrade slowly with only the LTS
versions.
If I understand correctly, you are saying that non-LTS packages should
ignore the recommendation of the FAQ (6.5, "package authors should not
make backwards incompatible changes to packages").
That doesn't sound like a good solution.
If I want to support users running versions of Racket that are a couple
releases old, it doesn't work.
If I want to depend on other packages, then in the absence of a standard
approach I've got to trust that they have the same notions about
compatibility and versions-encoded-as-package-names as I do. If I want
to support Racket back to X.Y, I had better hope that the packages I
depend on do too. That is, I'd have to figure out how each of them (and
all of their dependencies) handle compatibility instead of just trusting
that they all follow the single standard approach.
Finally, as a meta-point, is there any evidence that just throwing away
versions will work? Any precedents? So far, this seems like a classic
case of throwing the baby out with the bathwater: versions sometimes
cause problems... so we won't have them. Now we have the same problems
but fewer tools for handling them. (See also Eli's response.)
If planet2 is aimed at a problem that is restricted in scope somehow
that it doesn't need to worry about version issues, I still don't
understand what that narrower problem is. If I'm supposed to think about
planet2 as a way of distributing code, I'm still confused about what my
obligations are when I create a package and what I can rely on from
other packages.
Ryan
I would also hope that P2's lack of an ability to depend on the core
version would induce better backwards and forwards compatibility from
Racket in the version.
But I'm a bit radical on this front, so I assume that we will have a
robust alternative based on Carl's idea that uses P2 underneath it.
Jay
On Wed, Dec 12, 2012 at 1:13 PM, Carl Eastlund <[email protected]> wrote:
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 <[email protected]> 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
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
