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 <[email protected]> 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 [email protected]. >> To post to this group, send email to [email protected]. >> 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. 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.
