Package Registry Versioning - Sort by Pip convention for versioning of Python Packages (1.0.153 is the latest version, not 1.0.95)

Proposal

I recently migrated our old PyPi registry to our private GitLab server (a total of about 16,000 packages). I have noticed that when sorting by version, versions are treated like decimal values, rather than a composite series of integers. For example in a package with versions 1.0.95 and 1.0.153, version 1.0.95 is displayed as the most recent version, when in reality, version 1.0.153 is the latest version. This is a common issue across almost all of our packages, as some have been maintained for over a decade.

I believe this sorting behavior occurs because from the implementation perspective, 1.0.95 is considered 1.0.950, and thus a newer version than 1.0.153. Fortunately, the way versioning is sorted on the GitLab web ui does not impact the installation from the registry via pip (a python package retrieval mechanism). Version 1.0.153 in this example is indeed pulled when upgrading the package to the latest version.

My proposal is that the versioning on the web interface also sorts via the pip convention, rather than treating the last value as a decimal. Alternatively, GitLab could provide the user with more flexibility regarding how versions are sorted. I suspect it may be the case that the GitLab registry has a versioning convention that is not common for Python packages.