Oh then maybe I'm misunderstanding "deprecated". I was thinking of it from the narrow/selfish point of view of a (new system) package developer. In that system, deprecated can't mean "will be removed soon", because you can't ever remove things from a package. (Packages are supposed to be backward compatible, even with a new major version number. If you want to remove stuff, you're supposed to make another package. (I'm not trying to re-open that discussion, now, just follow the status quo.))
So I was thinking of it as purely advice/admonition: "Starting with version N, you ought to use Shiny instead of Finicky." However, Finicky will remain forever in that package per se. I don't know whether that's "deprecated" or not, but it's a thing. I'm curious to know the answer to Alexis' question: Semantics aside, how do I simply make something with a standard warning appearance? In many cases that's probably sufficient. I went looking for examples of this in the docs, so I could go look for its Scribble. But I couldn't find any. Alexis do you have a link to an example? On Tue, Oct 13, 2015 at 11:48 AM, Vincent St-Amour <stamo...@eecs.northwestern.edu> wrote: > Someone correct me if I'm wrong, but my understanding is that, in the > context of Racket at least, "deprecated" implies that we will be > removing that code in the near-ish future. As we recently did for, e.g., > class100. > > My understanding is also that we don't want to remove things like > mzscheme, mzlib, planet, or compatibility. So using the above definition > of deprecated, we don't want to deprecate those. > > With that said, though, I very much agree with your sentiment: we should > have a clear way of signaling that people shouldn't use those. As we've > learned from the "unstable" collection, even large warnings are not > enough for that if there's valuable stuff in there. > > With the package system, however, it's possible to remove code from the > main distribution without breaking code that depends on it (it just > needs the right dependencies). So it should be possible to essentially > do the same for the compatibility-lib package (which contains most of > the things I suspect you'd want to deprecate) as we did for the > unstable family of packages, and move it out of the main distribution. > In the process, we can move the last few bits of useful functionality > that exists in these collections, but not in more modern Racket > equivalents. > > If we do that, then most people won't have that package installed, it > won't show up when they search the docs, and we win. And we can do that > without breaking anyone's code (assuming they have the proper > dependencies already). > > (That may be trickier to do with planet, though, as I think it may be > embedded pretty deeply into our toolchain.) > > Doing that for compatibility-lib and other non-recommended libraries > (like srfis) is on my to-do list, but not currently on the top. > > Vincent > > > > On Mon, 12 Oct 2015 19:01:51 -0500, > Neil Van Dyke wrote: >> >> There's still a problem of people stumbling upon deprecated stuff in the >> Racket manuals, and going to a lot of trouble to use it without >> realizing that it's deprecated. >> >> For a very quick fix, how about appending "[DEPRECATED]" to certain >> manual titles, as an easy way of marking each page of the manual? >> >> For example, the title: "PLaneT: Automatic Package Distribution" >> is changed to: "PLaneT: Automatic Package Distribution [DEPRECATED]" >> >> This could also be done to individual "compatibility" chapters/section >> headers of otherwise non-deprecated manuals. >> >> Also, move things like the PLaneT manual to the "Legacy Languages and >> Libraries" category. Maybe append "[DEPRECATED]" to the titles of the >> other manuals in that category, as well. >> >> Neil V. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Racket Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to racket-dev+unsubscr...@googlegroups.com. >> To post to this group, send email to racket-dev@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/racket-dev/561C49EF.3010805%40neilvandyke.org. >> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "Racket Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-dev+unsubscr...@googlegroups.com. > To post to this group, send email to racket-dev@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-dev/m2twpupy61.wl-stamourv%40eecs.northwestern.edu. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+unsubscr...@googlegroups.com. To post to this group, send email to racket-dev@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/CAGspUn2FjXnohmT88Tefm5C5QZ54-%2BiVg6nff4-xRkdw7s-TtQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
