[racket-dev] planet2 and versions

On Wed, Dec 12, 2012 at 4:01 PM, Ryan Culpepper <ryan at cs.utah.edu> wrote:
> 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").

I don't consider different versions of Racket as backwards incompatible changes.

> 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.

Then it is your duty to not depend on new features of Racket and
Racket's responsibility to keep the old interfaces alive.

> 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.)

Most OSes work like this because you can't install different versions
of the same package. Yes, they have version numbers, but the only
useful semantics of those is that the installed and the current
version number aren't equal (so you need to update.) If you also allow
Package A to depend on Package B's version X or above, then
essentially you are allowing Package B to switch to Package B' at
version X, because before that point it did something different. P2
just makes that explicit.

Jay

> 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
>>>
>>
>>
>>
>



--
Jay McCarthy <jay at cs.byu.edu>
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93