Open TSNoble opened 3 years ago
We do not have many command line options, we only have options for verbose, help, and no-input, neither of which I use. :-) I prefer to just answer the questions, mostly just pressing Enter to accept the default answers.
But the bumpversion
command has some options. And we have issue #367 where someone wants to copy those options to the postrelease
command. And now we have the current issue.
I guess the trickiest may be that you end up getting values from too many places, making it harder to see where a command got a value from:
setup.cfg
~/.pypirc
setup.py
(version)For most of those, it gives a default value, and we still ask a question about it, for which you can accept the default, or override it.
For command line options, we should probably treat those as not overridable. So when you pass --version=1.2.3
, we no longer ask you which version you want.
During the postrelease phase, we should do nothing with this version option. But calling postrelease --version=1.3.0
may still make sense, similar to issue #367 where postrelease --feature
is wanted. Well, maybe worry about that later.
@reinout Are you okay with adding more command line options to zest.releaser
?
The --version
is one that might be useful.
Though I'd have to ask which version it is: the one we're releasing as (prerelease, release) or the one we want to bump the version to (postrelease).
Brainstorming: is there a way to do it in a more generic way? We have those nice documented data dictionaries (https://zestreleaser.readthedocs.io/en/latest/entrypoints.html#common-data-dict-items), is there something we can do with that? fullrelease --postrelease-new_version=1.1
to set new_version
in the postrelease data dict?
I'm using zest in a project and was wondering if it'd be possible to pass
--version=a.b.c
as a command-line parameter to theprerelease
/fullrelease
commands? I'm using zest as part of an automated release Github Actions workflow, so it'd be super handy to be able to pass the desired version directly from the workflow input to the command, rather than implementing some kind of custom logic or using different workflows for major/minor releases.I'd be happy to submit a PR making the change if that sounds sensible!