-
Notifications
You must be signed in to change notification settings - Fork 34
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
CLI flag to bump version based from working dir instead latest VCS tag #188
Comments
The work around I now used successfully, is to delete the tag of the newer 1.1.0rc2 only locally, then do a bumpver update with the -n flag (no fetching). Afterwards a bumpver show retrieves the locally deleted tag again from the origin.
|
Sounds like a reasonably common use-case. Out of curiosity, for your use-case, I would assume ideally, bumpver would only consider tags that are for an ancestor of the current HEAD? Suggestion for the CLI parameter
Not sure about the name, but that's the idea. You have any interest in working on a PR for this? |
Hi, thanks for the response. For me, your I might be interested in working on a PR for this, thanks for the suggestion, but it is not going to happen soon, the earliest would probably be mid-November or even later, over the Christmas holidays. |
I just thought of maybe even a more wholesome solution to this problem. The 'SSOT' idea/argument for choosing the |
I'm interested in working on a PR for this, as I'm running into the same issue right now. $ git checkout dev
$ git tag --list --merged
0.1.0
0.2.0b0
$ git checkout master
$ git tag --list --merged
0.1.0
0.1.1
$ bumpver update --no-fetch --patch --dry
INFO - Working dir version : 0.0.0
INFO - Latest version from VCS tag: 0.2.0b0
INFO - Old Version: 0.2.0b0
INFO - New Version: 0.2.1b0 I would implement it the way as @demmerichs suggested:
I also would make this behavior the default and don't even bother adding a I would appreciate some feedback on this. |
Hi, I totally forgot about this potential PR. Thanks for picking it up again :) Your proposal sounds good to me and I would be fine with it for now. However, I think adding the flag would be the "better" more long-term solution, for a couple of reasons:
I really hope, the owner responds to this and gives you a green light for this, whichever shape this feature will take form :) |
Hi, 1. and 3. sounds plausible to me. As for the second point: I tend to disagree and wouldn't add some kind of |
I've not had time to fully consider the suggestions by @malnvenshorn, so I'll just give some feedback for consideration. Skimming over it, reading "make this behavior the default", I'd just caution to think about maintaining backward compatibility. I don't want any CI pipelines to break because of a change we make here.
So long as there are tags, they will be used. You can use bumpver without version control and also when there are no tags yet, in which case the config is used. So in principle the config is for bootstrapping and is ignored once tags are available.
My concern here would be the possibility of generating the same version number/tagging two different revisions, on different branches. Another minor concern would be maintaining support for mercurial, but I wouldn't reject the PR, so long as functionality is strictly expanded (i.e. worst case nothing improves for mercurial users, but nothing gets worse either). |
I wasn't aware of that. Thanks for pointing this out.
A check of
I have no experience with mercurial, but according to this stackoverflow question the mercurial equivalent would be |
I would probably focus on git and drop mercurial support for this. I think most users use git, and glancing over a short comparison of git and mercurial, it seems to me the latter is not intended to be used in a branching model, therefor this feature might be less relevant for such users. I'd be happy to also give feedback/do a code review for a potential PR, or assist in minor ways during development. |
I looked a bit into the source code and some further questions came up. Quoting the documentation
but that's not the case actually. Lines 678 to 680 in 277d893
Naming the parameter As you can see I'd also drop the Edit: Ok well that was bullshit 😆 The behavior has to change as VCS tags must be the ssot to make this work. |
Just to point that out again: this change will break current behavior. Let me explain this in two examples. You have two branches But this breaks existing behavior, because the results of the following commands would be different. Some example with the current behavior:
But with tags as single source of truth the result of the second command would be:
I'm open for thoughts and feedback! |
So to summarize: The current behavior is something like I think two questions/decisions arise from this:
I am leaning towards keeping the current behavior and introducing it also to the branch setting, mostly because of backwards compatibility reasons. |
I agree with you that we should keep the existing behavior of
Not necessarily as you can run This still leaves the question how we should handle such cases. |
Mh, so if I would bump the version with no commit, I would not put the version change in a later commit either, kind of squashed with something else, because that seems an antipattern to bumpver. And to all the users, doing this kind of antipattern, they probably have for themselves already some kind of work-arounds for those cases you described. Just to list a few workarounds: During cherrypicking also editing the commit to remove the version change, or do an interactive rebase after the cherry picking. I believe you can also just change the version line to something old in the config before calling bumpver, thus bumpver falling back to the newest tag. |
I think that's a good solution, if @mbarkhau is ok with this. |
Thanks @demmerichs and @malnvenshorn for thinking things through here. First some answers/comments.
Once the PR is working for git, I'll have a look if mercurial support isn't too difficult to add.
The current behaviour is not a bug. If there is a discrepancy, the documentation is wrong. Now I'll try to summarise what I believe we can agree on. The user should have control over what is considered the We could implement this with some fancy comma separation and give the user full control, but I'm inclined to not introduce a foot-gun.
When using |
Looks good to me. I guess |
Yes, that seems appropriate. |
Fixed with |
The title says it all.
I read the reasoning in the README under 'Bump it up' for making the decision to take as the current version the most recent one from the VCS tags, globally across all branches.
But there are use-cases, especially with release branches, where the current version should be taken from the current working directory. This is already shown in bumpver output, however I was expecting a CLI flag to switch this behavior if needed, but could not find it. More frustrating even is, that setting the version manually won't work either, as bumpver still compares this against the most current version it found.
In case you are interested, the use case I am facing currently:
Stable/main branch on version 1.0.1
Release branch with additional features on version 1.1.0rc2
In the mean time I want to push some minor fixes to the stable branch, e.g. incrementing it to 1.0.2.
To me it seems this kind of branch structure might be quite common so I was wondering, why bumpver is not supporting this kind of behavior.
The text was updated successfully, but these errors were encountered: