You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed that we have some packages where the upstream project is officially unmaintained or had no activity for 8 years. I think it would be helpful for package maintainers and users to mark such packages.
example: qsyncthingtray (last release 5 years ago, unmaintained)
abandoned (no update for X years)
example: syncthing-tray (last release 8 years ago)
I think we can keep such packages (like we do right now) for those that are still using them, but remove when they become broken or insecure. A package lifecycle diagram might be nice for the documentation.
We can show the project status in the search with a colored label: green, orange, blue
We could also include broken and insecure packages and show a big warning, so users know the packages exist and need some work.
With the new meta attribute, we can also add options like allowBroken:
allowUnmaintained = true; allowAbandoned = true;
(default true, so the behavior does not change. users can change that)
We can create a script to check how long a package (definition) had no update and check the upstream status.
We have to think about the wording to not conflict the project status with out package maintainership status. Many packages have no maintainer set, so they are technically unmaintained.
What do you think?
The text was updated successfully, but these errors were encountered:
Issue description
I noticed that we have some packages where the upstream project is officially unmaintained or had no activity for 8 years. I think it would be helpful for package maintainers and users to mark such packages.
We would have to add a new meta attribute like:
meta.project-status
(one word would be preferred)that can have several states
maintained
(default)unmaintained
(official upstream statement)example:
qsyncthingtray
(last release 5 years ago, unmaintained)abandoned
(no update for X years)example:
syncthing-tray
(last release 8 years ago)I think we can keep such packages (like we do right now) for those that are still using them, but remove when they become
broken
orinsecure
. A package lifecycle diagram might be nice for the documentation.We can show the project status in the search with a colored label: green, orange, blue
We could also include broken and insecure packages and show a big warning, so users know the packages exist and need some work.
With the new meta attribute, we can also add options like
allowBroken
:allowUnmaintained = true;
allowAbandoned = true;
(default true, so the behavior does not change. users can change that)
Also the option to allow single packages:
permittedUnmaintainedPackages = [];
permittedAbandonedPackages = [];
We can create a script to check how long a package (definition) had no update and check the upstream status.
We have to think about the wording to not conflict the project status with out package maintainership status. Many packages have no maintainer set, so they are technically unmaintained.
What do you think?
The text was updated successfully, but these errors were encountered: