Add state field/tag/flag to store WIP/Beta/Stable/Mature/Abandoned

[rubenwardy]

No description provided.

[Warr1024]

Rather than a single-select for a specific state (the members of which we could argue about) I think I'd rather see this handled sort of like the content warning flags. For example, WIP packages could be flagged with a "Warning: Incomplete" flag that users could filter by, while abandoned packages could be flagged with "Warning: Unmaintained."

There are certainly packages that demonstrate that (1) these states are not mutually exclusive, i.e. something can be both WIP and abandoned, and (2) the states are not necessarily a series or continuum either, since a package could become abandoned, but then re-adopted, maybe even by the original creator who has a change of heart.

Using the existing flag system would also simplify the implementation since we wouldn't have to add a new field or new filtering capabilities.

I very rarely ever see open source software projects (as a majority of CDB packages should be) that can make a stable and meaningful distinction between states like "beta", "stable", or "mature". Often "perpetual beta" is the stable state of open-source projects, including ones that see extensive production use, and "stable" or "mature" is usually more a matter of opinion that would be better handled by an end-user review process rather than a creator's assertion.

[Warr1024]

My suggestion to use tags is very similar to #210.

The main difference I think is that tags for curation may need to be managed by editor or other higher-ranked users as a matter of fiat for curating the suggested package list, while the tags I'm suggesting in #160 (comment) would be managed by the package author to make assertions about the package's state without the need for editor intervention.

[Calinou]

Can we use something akin to the maintenance status in Cargo.toml?

# The `status` field is required. Available options are:
# - `actively-developed`: New features are being added and bugs are being fixed.
# - `passively-maintained`: There are no plans for new features, but the maintainer intends to
#   respond to issues that get filed.
# - `as-is`: The crate is feature complete, the maintainer does not intend to continue working on
#   it or providing support, but it works for the purposes it was designed for.
# - `experimental`: The author wants to share it with the community but is not intending to meet
#   anyone's particular use case.
# - `looking-for-maintainer`: The current maintainer would like to transfer the crate to someone
#   else.
# - `deprecated`: The maintainer does not recommend using this crate (the description of the crate
#   can describe why, there could be a better solution available or there could be problems with
#   the crate that the author does not want to fix).
# - `none`: Displays no badge on crates.io, since the maintainer has not chosen to specify
#   their intentions, potential crate users will need to investigate on their own.

[rubenwardy]

[rubenwardy]

[Wuzzy2]

Thank you! I have to remember to update my package states eventually.