Imagine this
Your are browsing the Umbraco Marketplace for new extensions, and you find a tool that solves one of many problems you might have. You open the package description, fall in love and are ready to add the package to your project, but then… Staleness idenfitied. You check the repository of the package to find out that the project hasn’t been maintained in over a year.
Is this realy a problem?
Yes, obviously. We know that as developers we are all required to ensure that the tools we use are up to date and don’t come with any unexpected suprises. So why do we always have to verify all this by ourselves?
What can we do?
Well many things, but the first and simplets way of making sure that we don’t use these packages that are no longer activly maintained is perhaps to mark them as what they really are "STALE". Even better, with a stale status we could use the build in filtration to give the Marketplace traveller a quick way of removing these packages.
Side effects
If the packages are no longer visible on the marketplace by default because of the state and filter, the maintainer might actaully want to update the package and solve some of the issues found by the package users?
This is a hard one to be honest. Just like you, I value maintained packages that are kept up to date. But I value reliable packages and a developer that responds quickly much more.
I think that the last time package was updated does not neccessarily reflect the quality of the package or if the package gets maintained properly. If I created a package when Umbraco 17 came out and that package just works and doesn’t really require maintenance, it could go for 2,5 years (how long the LTS is supported) without any issues.
So hiding packages I’m not very fond of. But some kind of label or filter that informs you (without judging) might not be a bad thing perse.
Maybe I was to direct with the whole “no longer visible”, but yes a badge and a filter option. Also if a package lives for 2,5 years without any updates, the package would most likly be in a voulnerable state (CVE’s) - this is just statisticly.
I would think you would need to define very carfuly what makes a package “stale”. As noted by Luuk, what if the package does not need further development so does not get touched in a long while? Packages developed for v13 could be perfectly fine for v13 but since they don’t work in v17 doe we mark them stale if the dev does not wnat to learn the backoffice and update the package to v17? And I would disagree that even if a package has not been touched in a long time is is most likly voulnerable. I could create a package that adds a single data type the does not rely on any packages but just groups simple things together and once it works it just works and would not need to be touched until the backoffice is changed again. This package could live for years with no CVE, no need to update, and be a great pack but why would it need to be marked stale and hidden away?
I think your concern about no longer maintained pcakages is valid but I think it is not so simple a thing to call them stale and hide them.
make one or both of those a first class citizen on the results card?
(and allow sort order by those fields too?)
That should prompt the same check you’d do if you visited say a git repo, to determine if you needed to do further checks before committing to use the package?
Flags like..
