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 about bumping.
We have to update the documentation and explain to our users that:
- the
--no-bump flag and the release_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,
- if no
--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 the release_suffix: .packit.yaml key:
- if
release-suffix is None then we generate a Release number like this: {original_release_number}.{current_time}.{sanitized_current_branch}{git_desc_suffix}
- if
release-suffix is str 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
Packit has a
--no-bumpflag, since bump should mean increase the number of version, a user could expect that omitting the--no-bumpflag would result in a increased release number.Moreover we deal with releases and not versions, this also can be not easily understandable when talking about
bumping.We have to update the documentation and explain to our users that:
--no-bumpflag 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-bumpflag is given we do change the Release, and we update the SPEC file, following what we have in the--release-suffixCLI flag or in therelease_suffix:.packit.yamlkey:release-suffixisNonethen we generate a Release number like this:{original_release_number}.{current_time}.{sanitized_current_branch}{git_desc_suffix}release-suffixisstrthen 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_suffixis here: https://gist.github.com/majamassarini/f2ebf6a78ca8af189208e77074a16dff