[racket-dev] planet2 and versions

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 <cce at ccs.neu.edu> 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 <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
>>>
>>
>>
>> _________________________
>>    Racket Developers list:
>>    http://lists.racket-lang.org/dev
>>
>
>
>