Add development versioning scheming #601
Conversation
CONTRIBUTING.md
Outdated
| After meaningful updates, but without concrete plans for a release, the version can pre increased once in [pyproject.toml](/pyproject.toml) file and appended with a `.dev` suffix, e.g. `4.0.1.dev`. | ||
| Further development versions adjust their suffix in following increasing way `.dev1`, `.dev2`, ... |
There was a problem hiding this comment.
I would suggest that we (and by that I mean our release manager, @JelleZijlstra), increase the version to .dev after each release, even without any updates in between. This makes is clear that the current version is not identical to the released PyPI package, and we don't forget to increment the version number after a "meaningful" update.
There was a problem hiding this comment.
Yeah, I wouldn't want to manually bump this version between releases. We can do some packaging magic to make the version show up as 4.5.6.dev+<commit hash> or something, I think that's what mypy does?
There was a problem hiding this comment.
Thank you two for your feedbacks. I've changed the wording to reflect that only one update will be done.
There was a problem hiding this comment.
Thank your for your feedbacks. I've prepared a new version.
Additionally I would like to include how to install the dev versions, or rather that --force-reinstall is important as no installation is done when the versions match. I therefore would like to add the following:
To install or upgrade a local development version make sure to use --force-reinstall when using pip to install the latest version:
pip install git+https://github.com/python/typing_extensions.git --force-reinstall
I am just not sure if Contributing.md is the right place for or if it should go somewhere else.
CONTRIBUTING.md
Outdated
| After meaningful updates, but without concrete plans for a release, the version can pre increased once in [pyproject.toml](/pyproject.toml) file and appended with a `.dev` suffix, e.g. `4.0.1.dev`. | ||
| Further development versions adjust their suffix in following increasing way `.dev1`, `.dev2`, ... |
There was a problem hiding this comment.
Thank you two for your feedbacks. I've changed the wording to reflect that only one update will be done.
| 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`. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
| - After the release has been published on PyPI the version of the repositiory | ||
| is upgraded to the next [development versions](#development-version). |
There was a problem hiding this comment.
As a sanity check for whoever is making the release, I think it would be helpful to include an example of how the version number should be updated. I'd also use imperative voice here to match the other steps. E.g. "After making the release, update the version number in typing_extensions/pyproject.toml to a dev version of the next planned release. For example, change 4.1.1 to 4.1.2.dev."
| @@ -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) | |||
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
| Further subsequent updates, i.e. to `.dev2`, are not planned between releases. | ||
|
|
There was a problem hiding this comment.
I think this is implied by the previous description. Talking about what the project doesn't do might be confusing
In relation to #528 I've written a proposal on how and vaguely when to add development versions.
I've oriented myself on the packaging versioning, and decided against the hyphen
-suffix for pre-releases.Further input and ideas are welcome.