Hi Jay, Thanks for the recap. I suspected that I had enough context, so it helps to have confirmation from a core dev.
It seems I should leverage a patchwork of sources to support different use cases. ~slg ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, April 30, 2020 8:57 AM, Jay McCarthy <[email protected]> wrote: > 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. > > On Wed, Apr 29, 2020 at 12:47 PM Sage Gerard [email protected] wrote: > > > April 9th in the #general Slack channel taught me that there was no clean > > way to > > release a breaking change in a package. I'm open to working on version > > pinning > > support in raco pkg provided that a maintainer can walk me through some > > code. > > In the meantime, as much as I appreciate the efforts made in the current > > system, > > I'm considering stopping my contributions to the package catalog until > > further notice. > > I'm open to submitting packages if I am confident in their longevity, but I > > don't want > > to end up in the position I've been in for the last few weeks when planning > > a release. > > That position being an inability to release an edition that is not in some > > way "aware" > > of a prior edition. In my view, changing the package/collection name is an > > example of that problem, not a solution to it. > > I'm considering asking my users to specify different package sources in > > their info.rkt > > files when dealing with my work. Before I commit to that decision, I wanted > > to tap into > > those of you who have already been here. How have you handled breaking > > changes > > for your projects? How have you communicated with your users to make sure > > they > > were adequately prepared? Am I being too black-and-white about this? > > ~slg > > -- > > 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 [email protected]. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/racket-users/3tKIr3GrU9Jnl7V-5yzb52OL3mjt8XNe9F_Qv9HDKwy8xC4j9lQo2e5eGSle4ZFHAee_FiGVhr15lXoovUE6yqoARP-ZNi3kXXz8ETXdufg%3D%40sagegerard.com. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/64-_6PEVdP6dw67S-2haB3ogDOGv3HX1L8twXqXHDsiXktpUxs_79YMTgmn0U9lpvBhFrENOX5NHspleE-ncL2SIRChIDehEsBHK9cgYKQQ%3D%40sagegerard.com.
