Seems you are in trouble, if missing a public API based on semantic versioning you must know the rules which govern the release update.
Quote from Semantic Versioning 2.0.0 by Tom Preston-Werner
In the world of software management there exists a dread place called
"dependency hell." The bigger your system grows and the more packages
you integrate into your software, the more likely you are to find
yourself, one day, in this pit of despair. In systems with many
dependencies, releasing new package versions can quickly become a
nightmare. If the dependency specifications are too tight, you are in
danger of version lock (the inability to upgrade a package without
having to release new versions of every dependent package). If
dependencies are specified too loosely, you will inevitably be bitten
by version promiscuity (assuming compatibility with more future
versions than is reasonable). Dependency hell is where you are when
version lock and/or version promiscuity prevent you from easily and
safely moving your project forward.
As a solution to this problem, I propose a simple set of rules and
requirements that dictate how version numbers are assigned and
incremented. These rules are based on but not necessarily limited to
pre-existing widespread common practices in use in both closed and
open-source software. For this system to work, you first need to
declare a public API. This may consist of documentation or be enforced
by the code itself. Regardless, it is important that this API be clear
and precise. Once you identify your public API, you communicate
changes to it with specific increments to your version number.
Consider a version format of X.Y.Z (Major.Minor.Patch). Bug fixes not
affecting the API increment the patch version, backwards compatible
API additions/changes increment the minor version, and backwards
incompatible API changes increment the major version.
I call this system "Semantic Versioning." Under this scheme, version
numbers and the way they change convey meaning about the underlying
code and what has been modified from one version to the next.
I think you should rely to a more empirical method in which it is possible to extract the minimum fixed information, but in the examples that you have mentioned is very difficult to establish a pattern recognizable as:
[Major Release].[Minor Release].[hot Fix].[build]
from which tokenizing the strings with the dot as delimiter and then compare the integer translation side by side, begining from the left.
In essence, NO, if there are no uniformly accepted rules that govern the release of those software versions, NO, there is no algorithm that can help you; sorry.