Open majamassarini opened 1 year ago
Thanks Maja for the detailed description.
Is this just about the documentation or we should improve the tool as well (e.g. the man pages, CLI option names...)?
I would say at least the documentation.
If we had time I would change the --no-bump
flag and choose another name, something like --no-update-spec-release
. But then we need to change the code, the CLI, the man pages...
We can add a new CLI argument and deprecate the old one. Or, at least update the help for the old one...
So we can leave the issue in this repository. (I've been thinking about moving it to packit.dev but it looks like some changes would be nice here as well.)
Related to packit/packit-service#1760
Packit has a
--no-bump
flag, since bump should mean increase the number of version, a user could expect that omitting the--no-bump
flag would result in a increased release number. Moreover we deal with releases and not versions, this also can be not easily understandable when talking aboutbumping
.We have to update the documentation and explain to our users that:
--no-bump
flag and therelease_suffix: ''
on.packit.yaml
(the first one is for CLI the second one is for packit-service) mean we are going to use the Release number we found on the SPEC file. And thus we are not updating it in the SPEC file,--no-bump
flag is given we do change the Release, and we update the SPEC file, following what we have in the--release-suffix
CLI flag or in therelease_suffix:
.packit.yaml
key:release-suffix
isNone
then we generate a Release number like this:{original_release_number}.{current_time}.{sanitized_current_branch}{git_desc_suffix}
release-suffix
isstr
then we generate a Release number like this:{original_release_number}.str
. We will never increase the release number here and we will always generate the same release!A table with many examples on how to use the flags related with the
release_suffix
is here: https://gist.github.com/majamassarini/f2ebf6a78ca8af189208e77074a16dff