Mark packages as Deprecated / "this is not maintained anymore"

[simensen]

Packages stop being maintained. Sometimes new projects spring up and replace aging ones. It would be great to be able to mark a package as deprecated and optionally be able to forward to one or more alternatives.

Real world examples:

dflydev/twig-github-gist-sculpin-bundle is a package I intended to keep working on but have since replaced it with a more portable dflydev/github-gist-twig-bundle. I realize it is not appropriate to delete the older package, but it would be nice to somehow indicate that it really isn't meant to be used anymore.

@simensen: is there a way to mark packages at deprecated?
@Seldaek: yeah that'd be great, feel free to report on packagist :)
@Seldaek: a "this is not maintained anymore" flag on packagist would be good at least

[simensen]

This is somewhat related to #106 — I hit submit too soon, meant to include it in the post.

[simensen]

Should deprecated packages show up in searches? Or should they be very obviously deprecated; maybe via being faded/semi-opaque in search results or some other visual affordance?

[Seldaek]

@simensen I think they should still show up but yeah faded or with a flag sounds good. Now I don't like "deprecated" so much though, maybe "unmaintained" would be more explicit?

[Seldaek]

orphaned|abandoned might be better wording btw.

[simensen]

What about a community based system for voting things as no longer maintained? (or whatever word ends up being used?) Maybe a separate thing but somehow tied together? I'm thinking if a maintainer has moved on / no longer has access to packagist and is not likely to come back.

[Seldaek]

Yeah we probably need a way to flag a package as abandoned/malware/foo so someone with access can review.

[JamesMGreene]

👍

NPM has this feature, it's very useful.

[aymericbeaumet]

👍

It would be a great feature for Packagist.

[rdohms]

@Seldaek how do you see this playing down into composer?

IMO if composer installs a package marked as deprecated in Packagist, it should show an alert indicating the state and which package to replace with.

The other option would be to update the json file but i think this would open all kinds of pandora boxes and edge cases.

[Seldaek]

There are two parts to this I think:

• How to mark something is deprecated:
  • a field in composer.json: I don't like this very much because it might linger in tags and stuff if a lib is picked up again by someone
  • a button/setting on packagist: I think this would be preferable, and should IMO have also an optional field where you can indicate what package(s) is/are recommended instead (this does not always apply unfortunately)
• What to do about it:
  • show a warning on packagist on the package page and in the search results: we need that for sure
  • show a warning when the package is installed: this could be interesting, and could be a big PITA. Regarding how to actually do this. We can set the flag in the package metadata that's not an issue (the stuff composer downloads from packagist is not directly the composer.json from the packages, so it does not require modifying the packages inline). It'd work but I'm really not sure whether it's a good idea.

[rdohms]

@Seldaek

• On tagging: I agree on the tagging being done in packagist, not the composer.json
• On doing: I agree we need both, doing it only on packagist only solves the "searching for packages" we need something in composer to direct people to replace it. I think storing it in the metadata is the best place, but i'm not sure how the implementation goes, so i'll look into it.

Why are you concerned about this? My core beginner intuition does not ring any alarm bells.

Any way, i'm going to start on the packagist side of things, then we can workout the composer side on a separate issue in composer.

[Seldaek]

I am just wondering if it won't become a nuisance if you have
deprecation warnings all the time when you use something that just works
for you. I don't know how common this will be but yeah we can try it out
and tweak if people complain :)

[rdohms]

Reading up from NPM and what their deprecated means, i see 2 different scenarios:

• deprecate: can be applied to a version, meaning the owner suggests updating
• abandon: applied to package to say, its no longer maintained

So as mentioned above i'll take that direction and implement abandoned flag. We can look at deprecated later.

[rdohms]

@Seldaek ok i got the visual flag working and the button to mark as deprecated and point a replacement.

What other features do you want me to ensure are done before i add the PR?

• do you want a "un-abandon" button to reverse it? i'm thinking this should be maintainer/admin only.
• do you want a "report as abandoned" flow? If yes, how would you see it working? stored in db and such, or email alerts?

[Seldaek]

I think un-abandon is good to have for sure, as for the report button this can be done later/separately IMO because we need various sort of reports (abandoned, abuse, ..?).

[juliendidier]

👍
need it!

[Krozark]

+1