You could both send packages to the package catalog and instruct your users to use a different package source if they wish to use old versions. I don't see these two options in conflict with each other.
As an application writer, I am on the other side of this problem, by depending on other packages. Having limited time to work on my project I want to upgrade package dependencies at my own pace. The solution I found is to use git submodules and add each package as a submodule to my application. I construct a catalog of these packages, at an exact git commit, and simply run a raco pkg install, knowing that the exact version that I want will be there. From time to time, I update these submodules and allow some time for fixing any problems that might result from these updates. This has worked reasonably well so far, and I can reliably reconstruct older versions of the application knowing that all dependencies will be correct for that old version. For my part, for any packages that my application depends on, their authors can make any breaking changes they want, as this will not immediately break my application. At a later date I can review these changes, update my application and move to the new version. The only downside is that installed packages are at "user scope" rather than "application scope" so once installed from the git submodules, that package becomes available to all applications on my computer. So far this has not been a real issue, although I had to uninstall, switch catalogs and re-install a few times. I personally regard pkgs.racket-lang.org as the source for the latest package versions, for users which just started using the package. Users who need precise versioning, can always setup their own package catalogs (i discovered that it is a really simple process) Alex. On Thursday, April 30, 2020 at 12:47:25 AM UTC+8, Sage Gerard 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/b3b54ccf-b4f1-425e-802a-110d5ac26591%40googlegroups.com.
