BREAKING CHANGE does not appear to cause major version bump

[ttimbers]

The problem

Including BREAKING CHANGE: in an angular/conventional commit message is not causing a major version bump.

Expected behavior

Including BREAKING CHANGE: in the head or footer should cause a major version bump.

Environment

This is observed on GitHub actions using python-semantic-release/python-semantic-release@v8.3.0. We are using version 8.3.0 because of this issue: #723 (comment) (we are using Poetry).

This is the where we call the python-semantic-release/python-semantic-release@v8.3.0 action in our ci-cd.yml file: https://github.com/ttimbers/pycounts_tt_2024/blob/2ff5a798211ad4a8f72579aac07a6aa30642ae13/.github/workflows/ci-cd.yml#L65C15-L65C69

    - name: Use Python Semantic Release to prepare release
        id: release
        uses: python-semantic-release/python-semantic-release@v8.3.0
        with:
          github_token: ${{ secrets.RELEASE_TOKEN }}

Note: the we are using a GitHub PAT here with repo scope to deal with main branch protection.

Configuration

Here's the corresponding table in pyproject.toml:

[tool.semantic_release]
version_toml = [
    "pyproject.toml:tool.poetry.version",
] # version location
branch = "main"                             
changelog_file = "CHANGELOG.md"             
build_command = "pip install poetry && poetry build"            

https://github.com/ttimbers/pycounts_tt_2024/blob/2ff5a798211ad4a8f72579aac07a6aa30642ae13/pyproject.toml#L24

Logs

Here's the commit that should have led to the major version bump: ttimbers/pycounts_tt_2024@c17380f

And the corresponding GHA log:

• https://github.com/ttimbers/pycounts_tt_2024/actions/runs/7701792773/job/20988700111
• https://pipelinesghubeus11.actions.githubusercontent.com/1OM4pq7cYTFDQ5upeB61txBbUvce0MU7MZjHeB15jV3hmLI4OU/_apis/pipelines/1/runs/46/signedlogcontent/15?urlExpires=2024-01-29T20%3A29%3A10.5482124Z&urlSigningMethod=HMACV1&urlSignature=UrmZ15xvQZVE3xMZwQOx%2FZSAAdXZKn%2FTwIWErrg8nDY%3D

[codejedi365]

@ttimbers, thank you for reporting this. Ends up our regular expression was not considering Windows based commit messages which would have \r\n rather than just \n. If you are writing the commit message manually, I recommend using the bang (!) character in the subject line to indicate your breaking changes for the time being.

feat!: testing major release

Just an edit to the authors really.

BREAKING CHANGE: Added middle initial

You also might be able to set .gitattributes at the top level of your repository and force git to always use Unix line endings LF but I'm not sure if this applies to the commit messages rather than the files. Luckily, Git on Windows will make the transition seamless to you (converts to CRLF upon checkout but saves as LF).

[ttimbers]

@codejedi365 - thanks so much for the prompt response to the issue!

Adding a ! to the scope in the header did in fact work! See here: https://github.com/ttimbers/pycounts_tt_2024/actions/runs/7714526673

Interestingly, I am not using Windows, at least no knowingly... To test out these commits with PSR I was using the GitHub web application pen tool to edit the README and then commit the changes, and then the PSR action was being run using an Ubuntu runner. Maybe the GitHub web application pen tool is using Windows? I had never considered that before!

A follow-up questions, the use of ! with PSR's default parser is not included in your documentation (at least that I can find), would you welcome a PR to add this? I think this is important because it's also not in the angular docs, which PSR references.

Thanks again for the quick help!

[codejedi365]

Maybe the GitHub web application pen tool is using Windows?

@ttimbers That's quite possible that the web interface is written towards windows. I found it odd that your commit message had \n\n between the subject and the body and then the body paragraphs used \r\n as the new line separators. Likely a translation error from the html text area element to form data.

A follow-up questions, the use of ! with PSR's default parser is not included in your documentation (at least that I can find), would you welcome a PR to add this? I think this is important because it's also not in the angular docs, which PSR references.

As I'm only a contributor myself, I don't have much sway in if the PR is accepted or not so PRs are always welcome.

My thoughts on the matter though would be that we should probably deviate from the term angular style in PSR because the angular format transformed into a larger movement that defines the conventional commits specification. The conventional commits specification is where ! is documented and it is defined as an optional syntax for breaking changes. Personally, I would put more emphasis on redirecting people to the specification that we implement rather than redefine and maintain the same docs to document the specification that is out in the world and being maintained by version separately.

[bernardcooke53]

I think @codejedi365 has explained this pretty well - pretty sure the GitHub UI defaults to \r\n separators. #821 is going to get merged and then this shouldn't be an issue.

You also might be able to set .gitattributes at the top level of your repository and force git to always use Unix line endings LF but I'm not sure if this applies to the commit messages rather than the files. Luckily, Git on Windows will make the transition seamless to you (converts to CRLF upon checkout but saves as LF).

I also wanted to echo this - https://git-scm.com/docs/gitattributes#_eol should hopefully mitigate some of the inconsistencies, but it doesn't seem to apply to commits. It can however help make CHANGELOG entries consistent when you may have contributors working on multiple platforms.

If you want to ensure that text files that any contributor introduces to the repository have their line endings normalized, you can set the text attribute to "auto" for all files.

*	text=auto