Anitya is matching tag names that do not start with the configured prefix

[bowlofeggs]

Ken Dreyer reported that there was a new version of python-backoff available upstream, but noted that the-new-hotness had not filed any issues against it in a while, even though it did used to file issues.

I went to look at Anitya, and it is showing a tag from 2015 as the newest release:

https://release-monitoring.org/project/17020/

It does see the v1.10.0 release as well, but I guess it doesn't think it's newer than the 20150213.1 tag. Curiously, the project is configured to use a prefix of "v" when determining versions, which I would expect to make the 20150213.1 tag not count as a release.

Thus, I think the issue may be that Anitya is not properly matching tag names when version prefixes are configured.

[Zlopez]

Unfortunately, this is a known issue and is caused by the Anitya unability to sort different version schemes together. This is why it considers 20150213.1 as the newest (based on the RPM scheme). There are few enhancements tickets, that should solve this issue.

• Anitya should report every found version, not only latest #774
  This solution has one drawback, it will actually still think the latest version is still the wrong one, but it will at least notify user, that there is new version.

The next ones are probably only inside my head:

• Add ability to exclude specific versions from the sort algorithm or not retrieve them at all
• Introduce version streams, that will allow user to create categories of versions based on the prefix and sort them individually. This will be best for sorting versions streams like 1.* and 2.* and it could be useful for the-new-hotness to actually create PR against correct branch in dist-git,

The best solution will be to have the versions sorted the same way as on source page, but this will need plenty of refactoring and I'm not sure this could be done for every backend we support. It will not work for projects, that are releasing versions in order like 4.0 - 3.1 - 4.1. When thinking about it more it will be probably not that good idea.

The version prefix is just to tell Anitya, if it found this prefix in version remove it before sorting.

[ktdreyer]

Do you Anitya retrieved "20150213.1" before someone added the "v" prefix to https://release-monitoring.org/project/17020/edit ?

If you delete "20150213.1" and "20150210.1" from the database, will things "just work" at this pint, since the "v" configuration will tell Anitya to ignore those?

[Zlopez]

The prefix configuration only removes the prefix if present, it doesn't ignore the version without the prefix. Right now Anitya obtains every version available for the project (with exception for GitHub, where it's obtaining only newer tags) and the prefix is removed when shown on page.

[Zlopez]

This was solved with implementation of #898 which was released in Anitya 1.0.0.