Hi Sage,
Racket has a very high standard of backwards compatibility where we
strive for programs to work continuously after many many years. In
most cases, we've been able to live up to the standard with the core
pieces of Racket. I can think of only a few times where we broke
compatibility and they were really traumatic and I think we learned a
lot from them about what compatibility really means.
The package system reflects this ethos. As you know, you can give a
dependency a lower-bound, but not an upper-bound, because we have
always been fairly loose with adding functionality (although it is
technical backwards incompatible), but not removing functionality. If
you need to break old programs, then you need to make a new logical
package, i.e. choose a new name, perhaps by adding a number to your
old name.
If you need to remove functionality or otherwise break old code, then
you are not really working on the same package anymore, but a new
product with similar functionality. In the history of Racket, you can
see this with the change from `(module _ mzscheme ...)` to `#lang
scheme` to `#lang racket` and in the change from `(require mred)` to
`(require scheme/gui)` to `(require racket/gui)`. These are NOT just
advertising changes because of new names; instead, the name was a
result of the need to add or remove functionality, while still
allowing all old programs to continue working.
This is simply a social standard though. There is nothing that
technically prevents you from breaking compatibility, except that your
users may be upset. You can post things on the package server that
follows any rules you want, including conflicting with any other
packages.
If you do so, and if your users need to pin themselves to particular
versions there are broadly two techniques. First, you can create your
own package catalog. Most users typically use two catalogs: the "big"
one on
pkgs.racket-lang.org and another "small" one for your
particular release, where the core racket packages are pinned to
particular versions. When we were designing the package system, we
imagined that organizations would maintain their own catalogs of
audited versions of packages so they would not be surprised by any
automatic updates. Second, you can change your package source to pin
to a particular git revision/tag. This might be particularly useful if
a package relies on erroneous behavior of some package that was
otherwise fixed.
Jay
--
Jay McCarthy
Associate Professor @ CS @ UMass Lowell
http://jeapostrophe.github.io
Vincit qui se vincit.
> --
> You received this message because you are subscribed to the Google Groups "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
racket-users...@googlegroups.com.
> To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/3tKIr3GrU9Jnl7V-5yzb52OL3mjt8XNe9F_Qv9HDKwy8xC4j9lQo2e5eGSle4ZFHAee_FiGVhr15lXoovUE6yqoARP-ZNi3kXXz8ETXdufg%3D%40sagegerard.com.