-
Notifications
You must be signed in to change notification settings - Fork 63
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
feat: refactor Version.bump()
to accept bumping major/minor/patch/last
#452
Conversation
…the bumping logic.
I would also need some help/guidance for the python binding. |
|
Hey @hadim, this looks great, appreciate the PR! I can help you with the Python bindings if you have any kind of issues. |
I am not sure how to 1) propagate the Result and the Error 2) integrate the new enum VersionBumpType |
For propagating the Result and Error, you can return the PyResult type from functions & extend the For the |
Make sense! Should I keep |
@Wackyator @baszalmstra: LGTM - ready for another round of review. Thanks! |
/// Bump the patch version number. | ||
Patch, | ||
/// Bump the last version number. | ||
Last, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a Segment(uint)
type? So that we can explicitly select the segment to bump?
We might also consider that bumping non-existent segments should be possible. Usually, all non-existent segments are implicit .0
, so bumping the patch
of a 1.0
could also result in 1.0.1
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a Segment(uint) type? So that we can explicitly select the segment to bump?
Good idea. Will do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We might also consider that bumping non-existent segments should be possible. Usually, all non-existent segments are implicit .0, so bumping the patch of a 1.0 could also result in 1.0.1.
Don't you prefer to instead fail, so it also builds incentive for the user to explicitly use x.x.x
instead of x
or x.x
?
Unless you feel strongly here, I would prefer to let it for another PR (I can open a ticket if you want).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added support for VersionBumpType::Segment(i32)
in 9283770 (rust side only).
Self { | ||
inner: self.inner.bump(), | ||
/// Returns a new version where the major segment of this version has been bumped. | ||
pub fn bump_major(&self) -> PyResult<Self> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we had that integer option we could pass an int from Python (with -1 being the last element, for example), and bump like that.
Then in Python we could also define an enum for the different named segments and allow both, passing an enum or an int.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am fine with this Python API.
What we have so far is:
bump_major()
bump_minor()
bump_patch()
bump_last()
I can add the below as well:
bump_segment(int)
bump(enum)
Does that sound good to you?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Python side done at 4ac1858
I didn't implement bump(enum)
since it seems a bit overkill at this point, but let me know if you still want it.
Really nice work. I had some simple remarks. Let me know what you think! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good work, just a couple of nits. :)
Co-authored-by: Tarun Pratap Singh <101409098+Wackyator@users.noreply.github.com>
All good @Wackyator on my side. Out of curiosity: are you using VSCode and rust-analyzer by any chance? I'm asking because I do and noticed that any Sorry, I know it's not really related to that PR, but didnt want to open a new issue for this. |
I'm indeed using vscode and rust-analyzer for py-rattler, I usually open |
This looks good to me, others can point out anything I may have missed. |
Ok, thanks. I was trying to avoid that and after going into the rabbit hole I found that: {
"rust-analyzer.linkedProjects": [
"./py-rattler/Cargo.toml"
]
} into |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left one final comment with regards to the unit test but other than that this looks good to me!
See #449 for context.
VersionBumpType
Version.bump()
toVersion.bump(bump_type: VersionBumpType)
This PR is breaking backward compat but since rust does not support overloading or default args, I could not find a more creative way to keep backward compat. That being said, it might not be that much of a problem. If it is, please let me know, and I can always keep
bump()
as it is and create a new function.