BREAKING CHANGE does not appear to cause major version bump

[ttimbers]

BREAKING CHANGE does not appear to cause major version bump

[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