How to address long-term support for packages

[pedrolucasp]

I suppose this could be flagged as more of a discussion than anything for now.

So, I'm the maintainer of some Alpine packages, and one of them is Prometheus. Now, despite Alpine Linux being a rolling-release (sorta) distribution, we decided a long time ago to stick with Prometheus LTS versions instead of their new, almost-monthly releases.

This has obviously introduced a couple of spam, since anitya, correctly, dispatches notifications whenever a new Prometheus version is released. I've took a peak at the documentations and the ticket tracker to see if this has been discussed before, but apparently that has not.

Any heuristics we could apply here? I've seen that there is a stable_version property on the documentation, but I think that, according to the db/models.py, it sort of is the latest not pre-release version released?

I can help out with patching it, if offered some help and pointers on where to start. Thanks for your attention!

[Zlopez]

You are right, stable_versions are just versions that are not marked as pre_release.

I had an idea in the past to implement version streams for this use case (see #1540), but I never got time to implement it. Right now release-monitoring.org is not a priority for me.

[pedrolucasp]

You are right, stable_versions are just versions that are not marked as pre_release.

I had an idea in the past to implement version streams for this use case (see #1540), but I never got time to implement it. Right now release-monitoring.org is not a priority for me.

So streams would be stuff like nightly/canary (and their respective versions), and stuff like lts, stable_version? So a user could register these streams (why call it like that?), and point a heuristic?

[Zlopez]

Not really, the streams in my case means that there will be versions groups defined by regexes, like 3., 4.. It will also help with projects that changes their version scheme during their lifecycle. For example from calendar versioning (20250522) to semantic (1.0.0). It will help better sort the versions and allows for more variability from users.

Anitya can't really know which version is lts or nightly. It will be on whoever maintains the project on Anitya to set it up correctly.

Regarding name, I didn't really think of anything better.