Skip to content
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.

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

version: fix "next_" methods and increase test coverage #434

Merged
merged 1 commit into from
Aug 17, 2022

Conversation

radoering
Copy link
Member

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.)

Copy link
Member

@mkniewallner mkniewallner left a comment

Choose a reason for hiding this comment

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

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.

src/poetry/core/version/pep440/version.py Show resolved Hide resolved
@radoering radoering requested a review from a team July 31, 2022 20:18
@radoering
Copy link
Member Author

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.

@sonarcloud
Copy link

sonarcloud bot commented Aug 13, 2022

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 1 Code Smell

No Coverage information No Coverage information
0.0% 0.0% Duplication

@radoering radoering merged commit c9a54af into python-poetry:main Aug 17, 2022
bostonrwalker pushed a commit to bostonrwalker/poetry-core that referenced this pull request Aug 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants