Clarify version policy#777
Conversation
We will increase the patch version after a release. The minor version is increased when features are added. Also, use `dev0` instead of `dev`, since the former is the normalized version of the latter.
|
@AlexWaygood Could you have a look whether this makes sense? |
Codecov Report✅ All modified and coverable lines are covered by tests. @@ Coverage Diff @@
## main #777 +/- ##
=======================================
Coverage 97.26% 97.26%
=======================================
Files 3 3
Lines 7860 7860
=======================================
Hits 7645 7645
Misses 215 215
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
AlexWaygood
left a comment
AlexWaygood
left a comment
There was a problem hiding this comment.
Thank you! I still find some of this a bit confusing though (sorry, I'm a bit of a packaging noob).
In the original PR that added this policy, there was some talk of not having to manually do these bumps at all, and instead have this kind of thing be done automatically. I guess nothing came of that in the end?
| ## 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`. | ||
| Further subsequent updates are not planned between releases. | ||
|
|
||
| After a release the patch version is increased in [pyproject.toml](/pyproject.toml) and | ||
| appended with a `.dev0` suffix, e.g. `4.0.1.dev0`. | ||
|
|
||
| When a new feature is added we will increase the minor version once between releases. For example, from 4.0.1.dev0 to 4.1.0.dev0. |
There was a problem hiding this comment.
To be honest, I'm not sure we need this separate section? When putting out the releases over the last few weeks, I found it confusing that the Release instructions section at the bottom linked to this section, when this section didn't actually give any additional useful information compared to the release instructions.
Does anybody except the release manager really care what our development versioning policy is?
There was a problem hiding this comment.
I agree, I also found it confusing. I'll revert this change (mostly).
There was a problem hiding this comment.
Actually, I'll just remove it.
| 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. | ||
| - 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.1.2.dev0, see also [Development versions](#development-version). |
There was a problem hiding this comment.
the "next planned release" language here is a bit confusing, no? We never plan to do a patch release; we only make a patch release if there was a bug in the latest minor release. But as your helpful example later on makes clear, we should really bump the version from 4.1.0 -> 4.1.1.dev0 rather than 4.1.0 -> 4.2.0.dev0.
Also, what do we do for rc releases? After 4.17.0rc1 is released, does the version bump to 4.17.0.dev? What if we then make an rc2 release the next day? That might lead us to go from 4.17.0rc1 -> 4.17.0.dev0 -> 4.17.0rc2 -> 4.17.0.dev0 -> 4.17.0... so I guess after rc1 is released, we should actually bump the version to 4.17.0rc2.dev0, even if we don't plan for an rc2 release? Then the sequence would go 4.17.0rc1 -> 4.17.0rc2.dev0 -> 4.17.0rc2 -> 4.17.0rc3.dev0 -> 4.17.0 -> 4.17.0.dev0.
It would be really helpful to have explicit examples for what to do after an rc release, and what to do between rc releases, in my opinion. We always do rc releases these days, so it's pretty relevant to the release process.
There was a problem hiding this comment.
I've added some more examples and guidance. This seems fairly complex, but it really isn't. Before a release: Make sure the version number makes sense. After a release: Bump patch and add .dev0.
There was a problem hiding this comment.
So if we just released 4.1.1, when would we go to 4.2dev0 instead of 4.1.2dev0?
There was a problem hiding this comment.
I think we could (should?) bump the version to 4.2.0dev0 when adding the first new feature that would require a minor version bump. (That's how I do it for my projects.)
There was a problem hiding this comment.
Alternatively we could always bump the minor version after a release and use a separate branch from the last release when we need to do a patch release. (In my opinion the best solution for server projects with frequent changes, but probably a bit too complicated for typing-extensions).
3 participants
We will increase the patch version after a release. The minor version is increased when features are added.
Also, use
dev0instead ofdev, since the former is the normalized version of the latter.