id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
32161	Strict form of semantic versioning in Django.	Michael	nobody	"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"	New feature	closed	Core (Other)	3.1	Normal	wontfix	versioning, semver		Unreviewed	0	0	0	0	0	0