Open
Conversation
Also introduces consistency between test_versions_for* list names (pre-release tests include the method name)
Also introduces consistency between test_versions_for* list names (pre-release tests include the method name)
Also introduces consistency between test_versions_for* list names (pre-release tests include the method name)
Also tweak names to reflect method name
We can use this to increment dev
`BaseVersion.dev` is an int instead of a pair, but we can use the generic incrementor function just created.
Now we're not just checking whether the version is a prerelease or not, and instead checking to see if it has a dev component, we could do with encapsulating the condition.
The checks to prevent bumping the release segment now need to also ensure the version is not a developmental release.
Includes a few renames to try and seek some consistency. PEP440 may be precise, but the descriptive language is ill-defined.
- Include support for development versions in README - Last bit of reformatting to comply with black
Owner
|
hey @corriander ! sincere apologies for not seeing your pull request earlier. Thanks a lot for the detailed write-up! I'm curious if you actually used the changes in your PR to solve your use case. If so, did it work like expected in your workflow? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Well, this is nice! I was about to write something to increment versions automagically and I stumbled on this.
Sadly my use-case* requires dev versions and release versions only (perhaps with a release candidate option somewhere down the line) and I decided to have a stab at folding the functionality in rather than reinvent this particular wheel. Let's say I now intuitively understand both a) why you haven't implemented this yet and b) PEP440 discourages various types of dev and post releases...
That said, I've given it a shot.
0.1.1a1.dev1) so that can never happen. I think. I suspect this needs an optionaldevparameter everywhere and I felt I'd changed enough.next_dev()increments the pre-release everywhere, so...a1.next_dev()jumps to...a2.dev1.postNreleases can be handled similarly but I fear theifs involved.Anyway, hope this is useful. I'll try not to submit and run but I'm fairly snowed under at the moment so please bear with me :)