Allow marking a package as "discontinued"

[matanlurey]

Pub currently ranks packages based on the updated column:

This works great, until it doesn't. For the angular package, there is a historic, unsupported/maintained 1.x version that is presented instead of the newest 4.0.0-alpha version:

Under normal circumstances, this might be fine, i.e. ranking stable releases higher than unstable for viewing preference. However, package authors should be given an option (perhaps in an admin, or manually via a ticket system for the time being) to deprecate a version range.

In this case, imagine the following metadata was attached to the angular package:

{
  "deprecated": [
    "<4.0.0-alpha",
  ],
}

And the ranking was instead stable > unstable > deprecated.

[kwalrath]

Yes, please. See dart-lang/sdk#29911 for details, but I'd love to be able to deprecate https://pub.dartlang.org/packages/dev_compiler (and also to update its README) without doing a publish.

[isoos]

Nit: What you are referring to is not the search ranking, it is the package index ordering.

I see a few conflicts with deprecated as it is proposed:

• version 2.0 could deprecate 1.0, but what if 2.1 un-deprecates everything?
• version 2.3 could deprecate 2.3, and it could be just as valid as not allowing it

I think at one point the package author needs to answer the question: what version do I want to be used by others? And if I want to use the newer, why don't I release it as stable?

If you deprecate everything that was stable, then what does it mean to be unstable?

[isoos]

Another thing is that we could consider is to use discontinued instead of deprecated, because deprecation is the intent of the original developer, but others using it may consider it just fine a keep going and use it. It also simplifies the tracking, because a package is discontinued if and only if the last published version (stable or otherwise) has this flag set to true.

If the developer changes their mind, publishes a new version without the flag, it is clear that they continue working on it, and we clear the flag, handle it as a normal package.

Deprecation and removal of an API, and introducing a new one (like in case of angular) and its incremental rollout should be handled by a new major semver, but that is unrelated to whether the package is considered discontinued (or it could be called abandoned).

[isoos]

Any comment on discontinued?

Another item for it: If a package has no recent release (e.g. in the past 2 years), it can be considered discontinued.

[kevmoo]

Added a new issue for the notion of a "broken" release - #378

I think we should have separate concepts here...