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:

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.

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.

Looking to implement as part of the v10 release.

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?

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

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?

Still in backlog but getting close to a v10 release so it will be published soon

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?

Still in backlog

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?

Still in backlog