Manifest Deprecation Notice

[ddavness]

Reasoning & Use Cases

It's not uncommon that sometimes software gets overseeded, unsupported, and obsolete. And that said, sometimes the maintainer of said software just asks to use another project instead. The most prominent example is Python 2 which, if I'm not wrong, is already in End Of Life, but there are other cases, like TSLint deprecating in favor of ESLint, etc.

The idea here is that we could implement a deprecation property in the manifests. It should be used in the following conditions:

• The application is obsolete (generally, no longer maintained);
• More powerful/recent/popular tools are available to the public - usually endorsed by the old application's developer;
  OR
• The bucket maintainer is intending to remove the manifest AND/OR the download endpoint will become unavailable, within a short period of time (a month or less);

Usage

We can sketch a deprecation notice like this:

deprecated.json

{
    "version": "1.1.1.1",
    "##": "...",
    "deprecated": {
        "note": "This application has reached it's End of Life in 1st January 1970. The manifest will be removed in the following century.",
        "alternatives": [
            "some-other-package",
            "brand-new-software"
        ]
    }
}

Of course, we can also allow a shorthand for the property:

{
    "deprecated": "Note here"
}

Can be expanded to

{
    "deprecated": {
        "note": "Note here"
    }
}

Behavior

deprecated's behavior shall differ from the notes behavior in these ways:

• Text should always be colored when displayed (yellow or red);
• The notice should ALSO be displayed when after scoop update.
• Optionally, the manifest should be appropriately marked as deprecated on search results (scoop search deprecated)

Just like notes, the notice shows after installation and on running scoop info deprecated.