[Django] #32161: Please use consistent versioning in Django
Django
-------------------------------------+-------------------------------------
Reporter: Michael | Owner: nobody
Type: Bug | Status: new
Component: | Version: 3.1
Uncategorized |
Severity: Normal | Keywords: versioning, semver
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
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
--
Ticket URL: <https://code.djangoproject.com/ticket/32161>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Michael | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: versioning, semver | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Description changed by Michael:
Old 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
New 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
}}}
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
--
--
Ticket URL: <https://code.djangoproject.com/ticket/32161#comment:1>
Django
------------------------------------+--------------------------------------
Reporter: Michael | Owner: nobody
Type: New feature | Status: closed
Component: Core (Other) | Version: 3.1
Severity: Normal | Resolution: wontfix
Keywords: versioning, semver | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Mariusz Felisiak):
* status: new => closed
* resolution: => wontfix
* type: Bug => New feature
* component: Uncategorized => Core (Other)
Comment:
Michael, the [https://docs.djangoproject.com/en/3.1/internals/release-
process/#official-releases current version policy] is the result of a
broad consensus, see [https://docs.google.com/document/d
/1bC6A8qc4skCmlagOnp8U7ddgyC-1XxXCBTlgrW690i0/edit?usp=sharing the
summary]. You can start a discussion on DevelopersMailingList if you don't
agree.
--
Ticket URL: <https://code.djangoproject.com/ticket/32161#comment:2>