Don't mark project as outdated if both latest and old versions are present in a repo

[sdht0]

When browsing https://repology.org/projects/a/?inrepo=nix_unstable&families_newest=2-&outdated=True, I see entries such as:

Since the latest version is already present (along with older versions), this project shouldn't be marked as outdated, no?

[AMDmi3]

Generally (when packages with different versions package the "same thing") it shouldn't, but here (see project page) 0.19.0 are ruby modules, 0.16.0 are python modules, 0.13.0 is Haskell module, and the rest are C libs (all come from the same repo and share release cycle). Python, Haskell, and C bits are all outdated, and one of two C packages is marked as legacy in presence of higher version of the "same thing" as you expect.

[sdht0]

Ah I see. That explains most of the entries I was curious about.

How about https://repology.org/project/varnish/versions? I see:

Is it because the latest version is vulnerable? Otherwise both the entries look the same.

[AMDmi3]

There's another aspect. For some projects which have multiple branches developed in parallel (such as 7.x and 6.x) Repology also takes into account existince of newer versions in respective branches. Here, 6.0.12 is deprecated because there are newer 6.x versions. It would be considered legacy if the repository provided any of these.

It's not correct in this case though, because varnish has unusual release cycle where 6.0 is lts while 6.[123456] are deprecated. This can't be handled out of box and I'll fix that manually it by putting 6.0 into its own branch, which would make 6.0.12 treated as legacy as long as there's no 6.0.13 or later version available.

[sdht0]

Makes sense. Thanks a lot for taking the time to explain! I think we can close this issue now.

Repology is really cool in how it's taming the wild west of Linux distros a little.