Opened 4 years ago
Last modified 4 years ago
#32161 closed New feature
Please use consistent versioning in Django — at Initial Version
| Reported by: | Michael | Owned by: | nobody |
|---|---|---|---|
| Component: | Core (Other) | Version: | 3.1 |
| Severity: | Normal | Keywords: | versioning, semver |
| Cc: | Triage Stage: | Unreviewed | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
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
How 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