Discussion: Upgrade repo version after a release to `dev` to not match release version

[Daraan]

A while ago to do some tests I wanted to upgrade my current typing_extensions version to the current GitHub version by using
pip install git+https://github.com/python/typing_extensions.git.

I also blame pip here because it does not tell that it doesn't install anything. pip did 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-reinstall to 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.

[JelleZijlstra]

Sounds good. We can update the release instructions in the repo to mention this.

[Daraan]

#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:

1. Minor increase - Order: 4.1.1 -> 4.2.0.dev -> 4.1.2 -> 4.2.0.dev -> 4.2.0
2. 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.git will 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.