Strict form of semantic versioning in Django.

[Michael]

Hi,

I maintain a Django package that has recently started failing in CI with no new source code or explicit dependency changes. Naturally - since nothing changed in my source code I assume that maybe Django itself introduced this regression in a patch version release. So when I check the pip install logs I see this:

Collecting Django==3.1
  Downloading https://files.pythonhosted.org/packages/2b/5a/4bd5624546912082a1bd2709d0edc0685f5c7827a278d806a20cf6adea28/Django-3.1-py3-none-any.whl (7.8MB)
     |████████████████████████████████| 7.8MB 17.2MB/s eta 0:00:011

Now if you're a Django Core Maintainer and live and breathe Django, the above probably looks harmless to you. However if you're not "in the know" that Django named it 3.1 instead of 3.1.0, the above looks kinda like a loosely defined install. The mere existence of 3.1 and 3.1.2 creates just enough ambiguity to be uncertain about which version is actually installed. The thought process is like "I know 3.1.2 exists so why would 3.1.0 not exists? "

By using consistent semver (or any version style) you can remove this tiny amount of ambiguity and create 100% certainty and confidence.

Thank you,

Michael

[Mariusz Felisiak]

Michael, the ​current version policy is the result of a broad consensus, see ​the summary. You can start a discussion on DevelopersMailingList if you don't agree.