Skip to content

Bump flag behavior not consistent with documentation #570

Description

@majamassarini

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

Activity

  1. lachmanfrantisek commented on Oct 26, 2022

    @lachmanfrantisek
    Member

    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...)?

  2. majamassarini commented on Oct 26, 2022

    @majamassarini
    MemberAuthor

    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...

  3. lachmanfrantisek commented on Oct 26, 2022

    @lachmanfrantisek
    Member

    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.)

  4. transferred this issue frompackit/packiton Dec 5, 2022
  5. moved this from new to backlog in Packit Kanban Boardon Dec 8, 2022
  6. mfocko commented on Dec 15, 2022

    @mfocko
    Member
  7. removed their assignment
    on Oct 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions