version: fix "next_" methods and increase test coverage

[radoering]

Fixes and tests for next_major(), next_minor(), etc.

Fixed bugs:

• handling of dev releases of post releases (next major of 1.post1.dev0 should be 2 instead of 1, analogous: minor, patch, etc.
• next_patch for versions with more than 3 parts did not work
• deprecated next_prerelease for non pre releases due to its ambiguity and because the current implementation is just wrong for most cases (next pre release of 1.2 is not 1.2a0)
• deprecated next_devrelease for non dev releases due to its ambiguity and because the current implementation is just wrong for most cases (next dev release of 1.2 is not 1.2.dev0)
• introduced first_devrelease analogous to first_prerelease

One 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 of 1.2 could also be 2.0a0 for example depending on the release plan.)

[radoering]

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.

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.

[sonarqubecloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
1 Code Smell

No Coverage information
0.0% Duplication