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 <jay.mccar...@gmail.com> 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 s...@sagegerard.com 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 racket-users+unsubscr...@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. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/64-_6PEVdP6dw67S-2haB3ogDOGv3HX1L8twXqXHDsiXktpUxs_79YMTgmn0U9lpvBhFrENOX5NHspleE-ncL2SIRChIDehEsBHK9cgYKQQ%3D%40sagegerard.com.
