Incorrect/Different project versions causes other repositories to be marked outdated

[Sigmanificient]

Hi, I am a small maintainers of a bunch of packages from nixpkgs and i use repology to track which of the packages i maintain are need to by updated.

However, it seems that Incorrect/Different project versions causes other repositories to be marked outdated.

Examples

For instance, the wakatime package has a special version dedicated to macOS using a different repository, and thus, as a different way of versioning it. All other repositories packages are marked as out of date, for the incorrect reason:

While they are out-of-date, the upstream release is currently the version 1.90.0. Only going to the related tabs (which i didnt know how behforehand) clear this confusion:

This might be due to the repository build packages named causing clarity (some wakatime-cli are being called wakatime), but it would be nice if this could somehow be resolved (maybe using the source url?)

Once again, the cdelc project follow the same issue. This time however, the related section don't not help to categorize the sub-projects:

All the 2.5 version are up to date, according to the source that they are using (ridiculousfish's repo or cdelc website download link) but paul-j-lucas's fork causes them to be marked as outdated. (Since both are technically a fork, as the original version seems lost, maybe they should be separated from each other on repology?)

Another project is rasm. It is also due to 2 different upstream source to have been chosen for packaging it. No related section appears for it.

Problem

This was a small listing from the package that i maintain on nixkgs, that fall into this problem, I believe that it occurring 3 times show that it may also occurs for many others.

What led me to open this issue as other and not Version ignore, is the aim of establishing a discussion about repository packages marked as outdated due to the different sources not being separated. create a system of "sub-packages", based on the upstream source? It seems like a good idea to me, but there maybe is some technical difficulties doing so.

I am waiting for your return on the matter, and hope this will help to find a way of tracking outdated packages more accurately. Thanks.

[AMDmi3]

We cannot rely solely on upstream urls because

• There may be many different urls for a single project, and it's impossible to match these.
• Not all repositories provide upstream urls.

You submit a PR with split rules for each project you encounter, that's it.

[Sigmanificient]

I see, I will try to submit split rules for these packages, and possible issues i may run into, to help improving your project then! Thanks for the quick reply, and have a nice day

[AMDmi3]

I've already dealt with wakatime, and I don't see any action required for other projects, as both only have one valid upstream.

[Sigmanificient]

I've already dealt with wakatime, and I don't see any action required for other projects, as both only have one valid upstream.

cdelc has two:

• https://github.com/paul-j-lucas/cdecl (version 16.3, used by FreeBSD Ports, Gentoo, LiGurOS, openSUSE Leap)
• https://github.com/ridiculousfish/cdecl-blocks (version 2.5)

[AMDmi3]

I don't see mentions of ridiculousfish in any packages Repology knows.

[Sigmanificient]

To be fair, it seems like a fork of the 2.5 version with some improvement, not sure where is the official source of the 2.5 then, but it is not paul-j-lucas's version

[AMDmi3]

"Official" source for 2.5 is a tarball on ibiblio, dated 1996. I can't consider that a valid upstream while there's maintained fork.