Skip to content

Allow --no-tag to overwrite --commit #949

Description

@beatreichenbach

Description

This is related to the command semantic-release version:

I would like to run semantic-release without tags for this use case where another process creates a tag.
However as described in the documentation --no-tag doesn't apply to the --commit step.

Is there a reason that --no-tag only applies to the tagging step?
Would it be possible for --no-tag to also apply to the --commit step?

Use cases

With the current setup running --commit makes --tag/--no-tag useless as it will never create a tag different from the tag that is created by --commit, is that right? If that's the case, then there shouldn't be anything in the way for us to set it up so that --no-tag also applies to the tag created by --commit.

Possible implementation

I'd be happy of course to create a PR but wanted to check with what you all think.

Activity

  1. codejedi365 commented on Jun 8, 2024

    @codejedi365
    Contributor

    Is there a reason that --no-tag only applies to the tagging step?

    It's more of a historic thing that is not evaluated together. I added the --tag/--no-tag because my migration from v7 to v8 was broken while --commit/--no-commit existed already. I personally wanted to just use PSR to stamp the version into my codebase and run the build command and then stop which required --no-commit and --no-tag. Otherwise I had to manually remove the tag (I wasn't releasing yet). I made --tag/--no-tag mirror the commit option and separated the two actions and left commit as it was. I was not an advocate for the use of a version commit so I just left the commit options alone as I was fairly new to the project.

    Would it be possible for --no-tag to also apply to the --commit step?

    We already have the --push/--no-push action dependent on --tag and --commit so it would probably just be considered at the same point in the code. As for if it should...

    With the current setup running --commit makes --tag/--no-tag useless as it will never create a tag different from the tag that is created by --commit, is that right? If that's the case, then there shouldn't be anything in the way for us to set it up so that --no-tag also applies to the tag created by --commit.

    Yes, creating a commit with the version identified is kinda silly if you don't end up tagging it. PSR no longer reads commit messages to determine versions, so it would identify the same version from the same set of tags regardless if the last commit was a version commit or not. To be clear though, --commit does NOT create a tag.

    To summarize the result:

    • --no-tag implies --no-commit
    • --tag does NOT imply --commit

    which means:

    Commit Tag Option Result
    --commit --tag creates version commit & version tag on commit (default)
    --no-commit --tag creates a tag on the last user commit of the branch, no commit made
    --commit --no-tag No tag and no commit is made, versions are stamped & build_command executed
    --no-commit --no-tag No tag and not commit made, versions are stamped & build_command executed

    After writing this, yes I don't think this will cause any problems to have one imply the other, however, I do believe this will be a breaking change when added.

  2. beatreichenbach commented on Jun 16, 2024

    @beatreichenbach
    Author

    Hi @codejedi365,
    thank you so much for the detailed explanation. Sorry it took me a while to really grasp everything. I went though the code and made a pull request that I believe in the end actually makes some of these arguments more explicit.

    Now it is possible to do really almost anything. It is possible to only create a tag, to only create a commit and to push those independently. The biggest change is really just that we can now create a commit without a tag which can be helpful in some very niche circumstances.

    I did mark it with a breaking fix, as it changes the behavior of --commit --no-tag.

  3. added
    confirmedPrevent from becoming stale
    and removed on Sep 15, 2024
  4. codejedi365 commented on Sep 15, 2024

    @codejedi365
    Contributor

    Looking to implement as part of the v10 release.

  5. github-actions commented on Nov 15, 2024

    @github-actions

    It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?

  6. codejedi365 commented on Nov 15, 2024

    @codejedi365
    Contributor

    Still in backlog as I haven't done much of the v10 breaking change items yet but getting close

  7. github-actions commented on Jan 16, 2025

    @github-actions

    It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?

  8. 2 remaining items

  9. github-actions commented on Mar 20, 2025

    @github-actions

    It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?

  10. codejedi365 commented on Mar 21, 2025

    @codejedi365
    Contributor

    Still in backlog

  11. github-actions commented on May 21, 2025

    @github-actions

    It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?

  12. codejedi365 commented on May 21, 2025

    @codejedi365
    Contributor

    Still in backlog

  13. github-actions commented on Aug 20, 2025

    @github-actions

    It has been 90 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?

  14. codejedi365 commented on Oct 3, 2025

    @codejedi365
    Contributor

    Still in backlog

  15. github-actions commented on Jan 1, 2026

    @github-actions

    It has been 90 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?

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

    confirmedPrevent from becoming stalefeatureA new feature or a feature requestneeds-updateNeeds status update from maintainers

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions