Repository navigation
Discussion: Upgrade repo version after a release to dev to not match release version #528
Description
Activity
Sounds good. We can update the release instructions in the repo to mention this.
#601 was merged faster than I expected without resolving the conversations 😅
Currently there is a TODO left in CONTRIBUTING.md
For example, change 4.1.1 to 4.X.X.dev, see also Development versions. # TODO decide on major vs. minor increase.
To summarize #601 (comment): The open question is should it always be a minor or patch increase:
- Minor increase - Order: 4.1.1 -> 4.2.0.dev -> 4.1.2 -> 4.2.0.dev -> 4.2.0
- Patch increase - Order: 4.1.1 -> 4.1.2.dev -> 4.1.2 -> 4.1.3.dev -> 4.2.0
Normally you do not plan a patch release and would pin it to the next planned release (Option 1). But if a patch is released is results in a downgrade w.r.t. to (only) the dev version. In such a case trying to upgrade a dev version with
pip install -U git+https://github.com/python/typing_extensions.gitwill fail (silently) without adding another command. Option 2 will have a cleaner cycle here.@JelleZijlstra I think it might be up to you here what you think is best.
- linked a pull request that will close this issueClarify version policy #777
on Jul 3, 2026
A while ago to do some tests I wanted to upgrade my current
typing_extensionsversion to the current GitHub version by usingpip install git+https://github.com/python/typing_extensions.git.I also blame
piphere because it does not tell that it doesn't install anything.pipdid not perform an upgrade because the current release, which I had already installed, has the same version as the GitHub repo (4.12.2).Only after a while I realized that nothing was upgraded and I had to use
--force-reinstallto do it.I want to discuss if in the future, after some merged PRs, the version of the GitHub repo should be upgraded to a +1dev to not be equivalent to the latest release version.