wren ng thornton <w...@freegeek.org> wrote: > > Yes. There is no reason to put up a second Hackage for that one. > > Without changing anything in the current system, packages can just > > update their categories, so that they will be displayed below > > "Defunct" or something like that. This is fine, as only the > > categories of the latest version are significant. > > > > If you think this is a good idea, I will start with some of my > > packages. =) > > We've had package deprecation for a while, so the big trick IMO is the > documentation. Good descriptions of why the package is defunct and > suggestions on how people can do things better. > > If we're going to do it on Hackage itself, I think the big question is > one of style: should the documentation be all in the cabal file (i.e., > on the package description page, with no modules in the package); or > should we put the documentation into modules?
I think the package should be included in full, and the package documentation should clarify why the package shouldn't be used. The idea is that people can still download the code and see how not to do it. It also helps to keep legacy code working, because "bad idea" doesn't necessarily mean, "you could die if you use this". You might go as far as implementing special support for this in the cabal-install tool in the form of a flag like --allow-defunct. Greets, Ertugrul -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad.
signature.asc
Description: PGP signature
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
