If you package software or maintain automated builds, you know the drill. You need the latest stable version of some upstream project, and you'd think it's a simple API call. It isn't.
Release tags are wildly inconsistent. Some projects tag `v1.2.3`, others do `release-1.2.3-final`. Quite a few forget to mark their release candidates as pre-releases on GitHub, so the API happily returns a beta as "the latest release". And then there are projects that switch versioning schemes entirely mid-history, going from `v20150121` to `v2.0.1`.
I deal with RPM packaging, so I hit this constantly. Every upstream project required its own script. So I wrote `lastversion` to handle the mess, and it's been in production use for about 7 years now.
$ lastversion nginx/nginx
1.26.3
$ lastversion php/php-src --major 8.2
8.2.27
$ lastversion format "mysqld Ver 5.6.51-91.0 for Linux"
5.6.51
$ lastversion rocky
9.5
That last one pulls Rocky Linux's version from Wikipedia — not everything has a GitHub repo. `lastversion` works with GitHub, GitLab, BitBucket, PyPI, Mercurial, SourceForge, WordPress plugin directory, RSS feeds, Helm charts, and a few others.
The version parsing was the tricky part. Standard PEP 440 doesn't handle real-world formats like Java's `8u462-b08` or OpenSSL's `1.1.1b`, so I extended it. There's also heuristic detection for misfiled betas — when the micro version is suspiciously high (≥90) and it's not a date-based scheme, it's likely a pre-release.
You can also `lastversion download`, `extract`, or `install` releases directly. For CI scripts, the `-gt` flag gives you a non-zero exit code if no newer version exists. And if you maintain RPM specs, `lastversion update-spec nginx.spec` will update the version for you.
`pip install lastversion`. BSD licensed, ~400 GitHub stars.
