I think the case that Richard Mentioned is a key one to keep in mind. Having an unpublish could cause real problems. I like the idea of a "Hide" where it will no longer show up in the search and maybe have a place for a pointer to a different repo so if you go to the elm-check which is no longer supported it will point you to elm-test or the like.
Zach ᐧ On Tue, Nov 22, 2016 at 10:42 AM, Michel Rijnders <[email protected] > wrote: > > On Tuesday, November 22, 2016 at 12:33:40 AM UTC+1, Richard Feldman wrote: >> >> There is no unpublish feature, and it's important that there never be one >> <http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/>. :) >> > > That's too simplistic, you can also break lots of projects by publishing a > version of a package with a serious bug. And what if it's a security bug > that somehow exposes sensitive information? In such a case unpublishing > makes sense. > > >> If you want to deprecate a package, I recommend publishing a new major >> release that removes everything and replaces the README with an explanation >> of how the package is gone now (and perhaps what to use instead). >> > -- > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Zach Kessin SquareTarget <http://squaretarget.rocks?utm_source=email-sig> Twitter: @zkessin <https://twitter.com/zkessin> Skype: zachkessin -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
