ENHANCEMENT: Additional Suggestions for Deprecation

[bcurran3]

A couple ideas up for discussion to improve standardization of deprecation:

1. Deprecated packages could have standard/recommended versioning. I suggest 99.99.99.99. Stealing from food industry slang, I also like the idea of "86ing" a package, so 86.86.86.86 would be a good alternate. If a date is deemed helpful to mix into the formula than either 99.99.99.yearmonthday or 86.86.86.yearmonthday.
2. Remove all tags and replace just with "deprecated"
3. Strip out bugTrackerUrl, docsUrl, licenseUrl, malingListUrl, projectSourceurl, releaseNotes, copyright, and requireLicenseAcceptance
4. Keep id, title, version, authors, owners, packageSourceUrl, summary, description, projectUrl, and tags

Not that I expect others to use it, but I personally enjoy throwing the graphic into the description.

EDIT: This topic is really about RETIRING a package versus DEPRECATING a package. A new issue has been opened at https://github.com/chocolatey/choco-wiki/issues/110 to address it more directly.

[ferventcoder]

As long as we understand the difference between deprecation (which carries a migration pattern to something else, as described in my comments at #108) and what to do when the software a package represents is no longer available. Those are two distinctly different things.

[bcurran3]

A line for the docs that NEEDS to be changed:

"Add a dependency on the other package (if the package is being superseded)."

If the package is NOT being superseded, it's not being deprecated!

I've always assumed that "deprecated" does not necessarily, but could, equal "retired" whereas it has been brought to my attention that "deprecated" always means superseded.

Personally, I prefer prepending "[DEPRECATED]" over "[Deprecated]" as the deprecated status will be more noticeable.