[Feature request] ⭐ Filter old packages

[JCKodel]

There are a lot of abandoned packages (some with more than 2 years since last update, which will lead to dependency hell or the inability to upgrade the project in the long run because of outdated dependencies).

It would be nice if we could configure in the search results the maximum package age, in months (ordering by update date doesn't solve because the only useful sort ordering is search relevance).

Alternatively, a nice gauge showing the quality of the package would be awesome. Something like the pub points, where it reaches 0 when the last package update is >= 12 months.

Something like

★★★★★ = Package have the same current Flutter/Dart SDK (brand new)
★★★★✩ = Package is not updated in the last 3 months
★★★✩✩ = Package is not updated in the last 6 months
★★✩✩✩ = Package is not updated in the last 12 months
★✩✩✩✩ = Package is not Dart 3 compatible
✩✩✩✩✩ = Package is not Dart 2 compatible

[isoos]

I disagree: there are many packages that are more-or-less complete, and don't really need a regular update. A nice example is package:retry: it hasn't really changed in the past 3 years, another is package:ulid. Their popularity score reflects that they are in use, and I don't see why we should down-rank any of it.

I don't see how the frequency of the updates make it to quality measurement, besides the fact that the author has taken some action with the package - which in itself is just that, some action. For me the motivation to publish a new version is either to publish it because of some kind of contribution or fix, or some kind of metadata like topics or documentation. I would hate if I needed to publish just for the sake of publishing.

[sigurdm]

We could consider a search filter along the lines of: updated:6w

[JCKodel]

I disagree: there are many packages that are more-or-less complete...

Eventually, they all will stop working, especially those with dependencies (including the problematic ones: intl, analyzer, etc.)

I have an app written in 2018 and is always a really pain to keep it up do date due to abandoned packages and version conflicts =\

[isoos]

Eventually, they all will stop working, especially those with dependencies (including the problematic ones: intl, analyzer, etc.)

Right, and at that point, the analysis and scoring will reflect that (either through static analysis finding more warnings and errors, or the dependencies not resolving, or not being up-to-date). It seems to be better to rely on measurable degradations instead of proxies like age. Age may be bad, but may not be. An actual degradation that we can detect is more reliable.

[JCKodel]

An actual degradation that we can detect is more reliable

Agreed. In that case, environment: sdk: ${version} is taken into consideration now? I mean: if some package has an old sdk requirement, it counts towards its score? I guess that would help.

[isoos]

In that case, environment: sdk: ${version} is taken into consideration now? I mean: if some package has an old sdk requirement, it counts towards its score?

Yes, although more as a result of unable to complete the analysis. E.g. one old package that showcases these failures: