Skip to content

Add development versioning scheming #601

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
+8 −1
Open

Add development versioning scheming #601

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
24511a6
Add development versioning
Daraan May 21, 2025
f457e7a
feedback
Daraan Jun 28, 2025
31e48e2
dev version after a release
Daraan Jun 28, 2025
0468ba8
Apply feedback with open TODO
Daraan Jul 2, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 8 additions & 1 deletion CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,6 +24,11 @@ Starting with version 4.0.0, `typing_extensions` uses
[Semantic Versioning](https://semver.org/). See the documentation
for more detail.

## Development version
After a release the version is increased once in [pyproject.toml](/pyproject.toml) and
appended with a `.dev` suffix, e.g. `4.0.1.dev`.
Comment on lines +28 to +29
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In other projects, I've seen dev versions be named relative to the next "planned release", which can mean either a patch release or a major (feature) release. So for example, after releasing 4.0.1, the version number might get bumped to 4.1.0.dev. I think that's how htop does it as an example. I'm not sure whether doing something similar here would make sense or not.

FWIW, my personal weak preference is using a -dev suffix for generic dev version numbers that don't get bumped. The same style is used in e.g. mypy_extensions. It's a purely cosmetic difference -- -dev, .dev, dev0, etc all get normalized to the exact same version number.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you very much for the input and references, also sounds good and logical to me it had also crossed my mind. At that point it made more sense to me to avoid a downgrade in between:
4.0.0 (release) -> 4.1.0.dev -> 4.0.1 (patch-release) vs. subsequent increase even if there is not patch
4.0.0 (release) -> 4.0.1.dev -> 4.1.0 (no-patch-release).
Subsequent would allow pip install --upgrade typing_extensions to work as expected. On the other hand, in this situation pip will at least tell you that the requirement is already satisfied with 4.1.0.dev and you see that no upgrade to 4.0.1 was done.

I think we need to hear from the others first as well.

Further subsequent updates are not planned between releases.

# Type stubs

A stub file for `typing_extensions` is maintained
Expand Down Expand Up @@ -54,7 +59,7 @@ may have installed.
# Workflow for PyPI releases

- Make sure you follow the versioning policy in the documentation
(e.g., release candidates before any feature release)
(e.g., release candidates before any feature release, do not release development versions)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure this reminder is necessary. Would someone even think of doing this? I don't think creating a dev release accidentally is a concern, since the rest of the instructions (e.g. making a tag) would make that hard

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point with the tag. I also would not expect someone doing it, just explicit better an implicit?

In case we always increase in at least minor steps (4.1.0dev) I think we should note here or above that 4.1.0.dev -> 4.0.1 is the desired progress in case of patch versions.


- Ensure that GitHub Actions reports no errors.

Expand All @@ -68,3 +73,5 @@ may have installed.

- Release automation will finish the release. You'll have to manually
approve the last step before upload.

- After the release has been published on PyPI upgrade the version in number in [pyproject.toml](/pyproject.toml) to a `dev` version of the next planned release. For example, change 4.1.1 to 4.X.X.dev, see also [Development versions](#development-version). # TODO decide on major vs. minor increase.
Loading
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy