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

Add --show option to print only the version number #57

Open
florisla opened this issue Jan 10, 2019 · 19 comments
Open

Add --show option to print only the version number #57

florisla opened this issue Jan 10, 2019 · 19 comments

Comments

@florisla
Copy link
Collaborator

florisla commented Jan 10, 2019

External tools currently have to use grep and sed to extract the version number from the output of bump2version --list.

bump2version --dry-run --list patch | grep current_version | sed -r s,"^.*=",,

This is long and not very readable. Worse yet, Windows doesn't offer grep or sed unless you install Cygwin/GnuWin32/Linux subsystem for Windows[/...] .

Because it's a common need, I'd like to see (and can contribute) this instead:

# print current version
>>> bump2version --show
2.11.3
# print current version with modified serialization
>>> bump2version --show --serialize "Release {major}.{minor} patchlevel {patch}."
Release 2.11 patchlevel 3.
# print 'next' (bumped) version
>>> bump2version patch --show
2.11.4

I would propose that show enforces dry-run behavior so it never touches physical files. If you want to physically bump the version and also show it, you simply have to call bump2version two times.

@c4urself
Copy link
Owner

yep, let's do this -- I've run into this myself

@florisla
Copy link
Collaborator Author

I can work on this. Note that we would have to change [part] from a mandatory to an optional argument (#22).

Would you prefer the approach from #31 or #51 to accomplish this?

@florisla
Copy link
Collaborator Author

florisla commented Apr 5, 2019

Would you prefer the approach from #31 or #51 to accomplish this?

Any thoughts on this?

I've found that changing the behaviour of bumpversion.cli.main is very tough because it's so huge, with many different things going on.
I have a branch in the works that extracts all of that into helper methods; I'm going to work on that first.

@clbarnes
Copy link
Contributor

clbarnes commented Jun 6, 2019

Getting the next version would be great! Currently doing

bump2version minor --dry-run --list | grep new_version | awk -f= '{print $2}'

@kkpattern
Copy link

I can work on this. Note that we would have to change [part] from a mandatory to an optional argument (#22).

Would you prefer the approach from #31 or #51 to accomplish this?

How about adding subcommands. So it would be:

bump2version bump minor
bump2version show

@GreatBahram
Copy link
Contributor

Any progress on this feature? Would we see this feature in the next release?

@florisla
Copy link
Collaborator Author

florisla commented Dec 9, 2019

No progress yet. I'll look into it again, but can't make promises.

@GreatBahram
Copy link
Contributor

Is there anything I can do to achieve this feature in the next release? any help or contribution?

@florisla
Copy link
Collaborator Author

You've just motivated me to try to implement it this Christmas holiday :-)

@florisla
Copy link
Collaborator Author

@kkpattern I like the idea of subcommands, but that's hard to achieve in a backwards-compatible way.

For this feature I feel like it's not worth the hassle.

@clbarnes
Copy link
Contributor

clbarnes commented Dec 12, 2019

I think making part optional is a good way to go. The --new-version option could be refactored so that if part is given and not major/minor/patch, and can be interpreted as a version string, which is used as the new version (the old option could remain for compatibility purposes, possibly with a PendingDeprecationWarning).

The --show option without a part would show the current version. If a part was given, the --show option would prevent the actual update, and just show the version string if it were to be updated.

If part is not given, and no options are given which know how to behave without a part, the help message should be shown. I believe unix tools prefer to not throw errors when no arguments are given, so there's another gain there.

@florisla
Copy link
Collaborator Author

--show major could also be interpreted as "show me the current major part" (do not bump).

On the other hand, you could also achieve that using --show --serialize "{major}"

@c4urself
Copy link
Owner

Let's just implement --show and folks can reuse --serialize if they really must. In general I'd prefer the Unix philosophy and not try to stuff too many things into bump2version. Ex:| cut -d'.' -f1 for major is completely fine with just --show... again I understand Windows may not have this but I'm sure folks can figure out how to do this without the "everything and the kitchen sink" approach.

@tukataka
Copy link

tukataka commented Feb 6, 2020

@florisla Hello! It's useful feature for me. Do you have estimation for it ?

@florisla
Copy link
Collaborator Author

florisla commented Feb 7, 2020

Sorry it's slow. I have a working branch but each time I want to make a pull request I'm not sure all the code in there is necessary or understandable.

I'll aim for end of February for the pull request.

@twcurrie
Copy link

twcurrie commented Apr 5, 2021

The lack of this feature has also slowed me down as well, so I've gone ahead and put up a quick pull request. Happy to merge in the changes from your working branch @florisla, but I tried to keep it minimal.

@twcurrie
Copy link

twcurrie commented Apr 7, 2021

@florisla @c4urself Any thoughts on the PR I've put up?

@twcurrie
Copy link

twcurrie commented Apr 7, 2021

For other folks that are blocked, I've moved forward with defaulting to using the dependency management and packaging tool's to gather the current_version information: https://python-poetry.org/docs/cli/#version

@kdeldycke
Copy link
Contributor

For the record, this feature is going to be implemented in the new bump-my-version object. See: callowayproject/bump-my-version#15

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants