Repository navigation
Allow --no-tag to overwrite --commit #949
Description
Activity
- addedfeatureA new feature or a feature requestA new feature or a feature request
on Jun 8, 2024 Is there a reason that
--no-tagonly applies to the tagging step?It's more of a historic thing that is not evaluated together. I added the
--tag/--no-tagbecause my migration from v7 to v8 was broken while--commit/--no-commitexisted 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-commitand--no-tag. Otherwise I had to manually remove the tag (I wasn't releasing yet). I made--tag/--no-tagmirror 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-tagto also apply to the--commitstep?We already have the
--push/--no-pushaction dependent on--tagand--commitso it would probably just be considered at the same point in the code. As for if it should...With the current setup running
--commitmakes--tag/--no-taguseless 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-tagalso 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,
--commitdoes NOT create a tag.To summarize the result:
--no-tagimplies--no-commit--tagdoes NOT imply--commit
which means:
Commit Tag Option Result --commit--tagcreates version commit & version tag on commit (default) --no-commit--tagcreates a tag on the last user commit of the branch, no commit made --commit--no-tagNo tag and no commit is made, versions are stamped & build_command executed --no-commit--no-tagNo 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.
Reacted by Beat ReichenbachHi @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.- addedconfirmedPrevent from becoming stalePrevent from becoming staleand removed
on Sep 15, 2024 Looking to implement as part of the
v10release.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?
- addedneeds-updateNeeds status update from maintainersNeeds status update from maintainers
on Nov 15, 2024 Still in backlog as I haven't done much of the v10 breaking change items yet but getting close
- removedneeds-updateNeeds status update from maintainersNeeds status update from maintainers
on Nov 16, 2024 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?
2 remaining items
- removedneeds-updateNeeds status update from maintainersNeeds status update from maintainers
on Jan 19, 2025 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?
- addedneeds-updateNeeds status update from maintainersNeeds status update from maintainers
on Mar 20, 2025 Still in backlog
- removedneeds-updateNeeds status update from maintainersNeeds status update from maintainers
on Mar 22, 2025 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?
- addedneeds-updateNeeds status update from maintainersNeeds status update from maintainers
on May 21, 2025 Still in backlog
- removedneeds-updateNeeds status update from maintainersNeeds status update from maintainers
on May 22, 2025 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?
- addedneeds-updateNeeds status update from maintainersNeeds status update from maintainers
on Aug 20, 2025 Still in backlog
- removedneeds-updateNeeds status update from maintainersNeeds status update from maintainers
on Oct 3, 2025 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?
- addedneeds-updateNeeds status update from maintainersNeeds status update from maintainers
on Jan 1, 2026
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-tagdoesn't apply to the--commitstep.Is there a reason that
--no-tagonly applies to the tagging step?Would it be possible for
--no-tagto also apply to the--commitstep?Use cases
With the current setup running
--commitmakes--tag/--no-taguseless 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-tagalso 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.