version: fix "next_" methods and increase test coverage #434
Conversation
There was a problem hiding this comment.
Since there are breaking changes here, I'll let core members review the PR, but it looks like sensible improvements to me, especially prohibiting bump when we can't guess the default, as this could be confusing for users.
The handling of more than 3 parts for patch just reminded me about #409 that is still in draft, btw.
radoering
force-pushed
the
fix-next-version-methods
branch
from
749fb62 to
918a215
Compare
Actually, I don't think it's a breaking change. Something that is clearly wrong will be deprecated. Even if someone uses this wrong behavior, a deprecation warning will pop up and that's it. If we decide to allow next pre/dev release for stable releases despite its ambiguity, we can replace the wrong behavior by a correct implementation and remove the deprecation warning at any time. |
radoering
force-pushed
the
fix-next-version-methods
branch
from
918a215 to
5e7b476
Compare
|
Kudos, SonarCloud Quality Gate passed!
|
Fixes and tests for
next_major(),next_minor(), etc.Fixed bugs:
1.post1.dev0should be2instead of1, analogous: minor, patch, etc.next_patchfor versions with more than 3 parts did not worknext_prereleasefor non pre releases due to its ambiguity and because the current implementation is just wrong for most cases (next pre release of1.2is not1.2a0)next_devreleasefor non dev releases due to its ambiguity and because the current implementation is just wrong for most cases (next dev release of1.2is not1.2.dev0)first_devreleaseanalogous tofirst_prereleaseOne could argue that the next pre release can be determined by incrementing the last part of the version, so e.g. (
1->2a0,1.2->1.3a0). But it might be better to be explicit. (The next pre release of1.2could also be2.0a0for example depending on the release plan.)