Case sensitivity #54

New Issue

GiteaMirror · 2026-02-17T11:39:31-06:00

GiteaMirror commented

2026-02-17 11:39:31 -06:00

Originally created by @zeke on GitHub (Dec 17, 2018).

There seems to be no mention of case (in)sensitivity in the spec. Should there be?

Asking because I ran into this today and I'm not sure how to resolve it: https://github.com/probot/semantic-pull-requests/issues/39

@pvdlg does semantic-release require lowercase?

@greysteil is there a particular reason you've chose capitalized PR titles for @dependabot?

cc @tunnckoCore, maintainer of parse-commit-message, which appears to be case sensitive. (lowercase required).

Originally created by @zeke on GitHub (Dec 17, 2018). There seems to be no mention of case (in)sensitivity in the spec. Should there be? Asking because I ran into this today and I'm not sure how to resolve it: https://github.com/probot/semantic-pull-requests/issues/39 @pvdlg does `semantic-release` require lowercase? @greysteil is there a particular reason you've chose capitalized PR titles for @dependabot? cc @tunnckoCore, maintainer of `parse-commit-message`, which appears to be case sensitive. (lowercase required).

GiteaMirror added the triaged help wanted labels 2026-02-17 11:39:31 -06:00

GiteaMirror closed this issue

2026-02-17 11:39:32 -06:00

GiteaMirror commented

2026-02-17 11:39:34 -06:00

@greysteil commented on GitHub (Dec 17, 2018):

From Dependabot's side, I think those capitalisations are a mistake. I don't know when the bug was introduced, but at some point a couple of weeks ago I think a version of Dependabot shipped that accidentally capitalised the prefix.

Unfortunately that bug has been compounded by the updated Dependabot logic here, which means Dependabot will continue to use whatever prefix it last used in a merged PR - in your case that is now capitalised.

If you update the commit message on a Dependabot commit when merging it (e.g., using GitHub's squash and merge) then Dependabot should pick that up and start using that prefix instead.

@greysteil commented on GitHub (Dec 17, 2018): From Dependabot's side, I think those capitalisations are a mistake. I don't know when the bug was introduced, but at some point a couple of weeks ago I think a version of Dependabot shipped that accidentally capitalised the prefix. Unfortunately that bug has been compounded by the updated Dependabot logic [here](https://github.com/dependabot/dependabot-core/blob/4be5191878368469301a158f93bce830f787fcd2/lib/dependabot/pull_request_creator/message_builder.rb#L148-L162), which means Dependabot will continue to use whatever prefix it last used in a merged PR - in your case that is now capitalised. If you update the commit message on a Dependabot commit when merging it (e.g., using GitHub's squash and merge) then Dependabot should pick that up and start using that prefix instead.

GiteaMirror commented

2026-02-17 11:39:35 -06:00

@pvdlg commented on GitHub (Dec 18, 2018):

Yes semantic-release is case sensitive. I'm not sure why the decision was made. I probably didn't think about that case. It hasn't been a problem so far.
However the default for semantic-release is the angular convention which specifies each type in lower case, without clearly mentioning that the case matter. My personal reading of the Angular convention is the type must be lower case.

@pvdlg commented on GitHub (Dec 18, 2018): Yes semantic-release is case sensitive. I'm not sure why the decision was made. I probably didn't think about that case. It hasn't been a problem so far. However the default for semantic-release is the [angular convention](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines) which specifies each type in lower case, without clearly mentioning that the case matter. My personal reading of the Angular convention is the type must be lower case.

GiteaMirror commented

2026-02-17 11:39:36 -06:00

@stevemao commented on GitHub (Dec 18, 2018):

I think the spec should be a bit strict (case sensitive). But the tools can be a bit loose (case insensitive).

The angular team asked me to allow BREAKING CHANGE: to be case insensitive or at least configurable. So did the jshint team. There are (old) commits in those repos unfortunately have different casing (mostly made by casual contributors when they don't use tools like commitlint).

@stevemao commented on GitHub (Dec 18, 2018): I think the spec should be a bit strict (case sensitive). But the tools can be a bit loose (case insensitive). The angular team asked me to allow `BREAKING CHANGE: ` to be case insensitive or at least configurable. So did the jshint team. There are (old) commits in those repos unfortunately have different casing (mostly made by casual contributors when they don't use tools like commitlint).

GiteaMirror commented

2026-02-17 11:39:37 -06:00

@tunnckoCore commented on GitHub (Dec 18, 2018):

I noticed that tool, before few weeks. And think that all parts should be insensitive except the BREAKING CHANGE: - the type, scope and etc.

Dang, I forgot to set the i to the regex here which actually isn't currently a problem.

Yea, the problem comes from the increment plugin, but you always can create some similar plugin and use it instead of this one.

@tunnckoCore commented on GitHub (Dec 18, 2018): I noticed that tool, before few weeks. And think that all parts should be insensitive except the `BREAKING CHANGE: ` - the `type`, `scope` and etc. Dang, I forgot to set the `i` to the regex [here](https://github.com/tunnckoCoreLabs/parse-commit-message/blob/master/src/header.js#L40) which actually isn't currently a problem. Yea, the problem comes from the [`increment` plugin](https://github.com/tunnckoCoreLabs/parse-commit-message/blob/master/src/plugins/increment.js), but you always can create some similar plugin and use it instead of this one.

GiteaMirror commented

2026-02-17 11:39:38 -06:00

@zeke commented on GitHub (Dec 18, 2018):

I think the spec should be a bit strict (case sensitive). But the tools can be a bit loose (case insensitive).

☝️ This sounds good to me. Anyone want to take a crack at adding this to the spec?

@zeke commented on GitHub (Dec 18, 2018): > I think the spec should be a bit strict (case sensitive). But the tools can be a bit loose (case insensitive). ☝️ This sounds good to me. Anyone want to take a crack at adding this to the spec?

GiteaMirror commented

2026-02-17 11:39:40 -06:00

@dijonkitchen commented on GitHub (Dec 20, 2018):

This was discussed in #24, but I have found a good justification for lowercase if you are a fan of Google's reasoning for Go/Angular: https://golang.org/doc/contribute.html#commit_messages

@dijonkitchen commented on GitHub (Dec 20, 2018): This was discussed in #24, but I have found a good justification for lowercase if you are a fan of Google's reasoning for Go/Angular: https://golang.org/doc/contribute.html#commit_messages

GiteaMirror commented

2026-02-17 11:39:41 -06:00

@zeke commented on GitHub (Dec 20, 2018):

Thanks for sharing that old issue, @dijonkitchen. I searched but somehow missed it.

Hmm, for some reason that FAQ entry about uppercase vs lowercase is not showing up on the website, even though the website appears to be serving v1.0.0-beta.2 of the spec. @damianopetrungaro, you've been the most active deployer lately -- any idea what might be going on there? 🤔

From the above link:

A rule of thumb is that it should be written so to complete the sentence "This change modifies Go to _____." That means it does not start with a capital letter, is not a complete sentence, and actually summarizes the result of the change.

I like that. It works well with the GitHub convention of using imperative verb forms like change foo instead of changes foo or changed foo

All that aside, it seems this topic has already been discussed and a decision was made. Given that the Semantic Pull Requests bot is designed to play nicely with semantic-release which is case sensitive (lowercase required), I will probably update the bot to fail checks that are uppercase, but provide a helpful status message to indicate when the message would be valid if it was lowercase...

@zeke commented on GitHub (Dec 20, 2018): Thanks for sharing that old issue, @dijonkitchen. I searched but somehow missed it. Hmm, for some reason that [FAQ entry about uppercase vs lowercase](https://github.com/dijonkitchen/conventionalcommits.org/blob/2e14b1c858a620ab1e98b90191d0f796093f13c5/index.md#are-the-types-in-the-commit-title-uppercase-or-lowercase) is not showing up on the website, even though the website appears to be serving v1.0.0-beta.2 of the spec. @damianopetrungaro, you've been the most active deployer lately -- any idea what might be going on there? 🤔 From the above link: > A rule of thumb is that it should be written so to complete the sentence "This change modifies Go to _____." That means it does not start with a capital letter, is not a complete sentence, and actually summarizes the result of the change. I like that. It works well with the [GitHub convention](https://blog.github.com/2011-09-06-shiny-new-commit-styles/) of using imperative verb forms like `change foo` instead of `changes foo` or `changed foo` All that aside, it seems this topic has already been discussed and a decision was made. Given that the Semantic Pull Requests bot is designed to play nicely with `semantic-release` which is case sensitive (lowercase required), I will probably update the bot to fail checks that are uppercase, but provide a helpful status message to indicate when the message would be valid if it was lowercase...

GiteaMirror commented

2026-02-17 11:39:42 -06:00

@dijonkitchen commented on GitHub (Dec 20, 2018):

Yeah, seems to be in the "next" version of the content: https://github.com/conventional-commits/conventionalcommits.org/blob/master/content/next/index.md

@dijonkitchen commented on GitHub (Dec 20, 2018): Yeah, seems to be in the "next" version of the content: https://github.com/conventional-commits/conventionalcommits.org/blob/master/content/next/index.md

GiteaMirror commented

2026-02-17 11:39:42 -06:00

@tunnckoCore commented on GitHub (Dec 20, 2018):

My side is done. :) https://github.com/probot/semantic-pull-requests/issues/39 should be fixed too.

@tunnckoCore commented on GitHub (Dec 20, 2018): My side is done. :) https://github.com/probot/semantic-pull-requests/issues/39 should be fixed too.

GiteaMirror commented

2026-02-17 11:39:43 -06:00

@bcoe commented on GitHub (Dec 29, 2018):

👋 I'm late to the party, but I'd always assumed that the spec expected lower-case (except for BREAKING CHANGE which expects all upper-case); I agree that we should call this out explicitly on the website?

@bcoe commented on GitHub (Dec 29, 2018): 👋 I'm late to the party, but I'd always assumed that the spec expected lower-case (except for BREAKING CHANGE which expects all upper-case); I agree that we should call this out explicitly on the website?

GiteaMirror commented

2026-02-17 11:39:45 -06:00

@bcoe commented on GitHub (Dec 29, 2018):

anyone feel like making a pull?

@bcoe commented on GitHub (Dec 29, 2018): anyone feel like making a pull?

GiteaMirror commented

2026-02-17 11:39:46 -06:00

@damianopetrungaro commented on GitHub (Dec 30, 2018):

@zeke did you update the next version or the current beta?

@damianopetrungaro commented on GitHub (Dec 30, 2018): @zeke did you update the next version or the current beta?

GiteaMirror commented

2026-02-17 11:39:47 -06:00

@zeke commented on GitHub (Dec 30, 2018):

@damianopetrungaro no I haven't touched anything.

@zeke commented on GitHub (Dec 30, 2018): @damianopetrungaro no I haven't touched anything.

GiteaMirror commented

2026-02-17 11:39:48 -06:00

@bcoe commented on GitHub (Feb 18, 2019):

@zeke @tunnckoCore @damianopetrungaro where did folks land on this? do we not care about case sensitivity, with the exception of "BREAKING CHANGE" being all upper case?

This is potentially more user-friendly, and I'd be fine with this approach ... perhaps we update the spec to:

1. Commits MUST be prefixed with a type, which consists of a noun, feat, fix, etc., followed by a colon and a space (types are not case sensitive).

@stevemao ☝️would this require sweeping changes to the parser?

@bcoe commented on GitHub (Feb 18, 2019): @zeke @tunnckoCore @damianopetrungaro where did folks land on this? do we not care about case sensitivity, with the exception of "BREAKING CHANGE" being all upper case? This is potentially more user-friendly, and I'd be fine with this approach ... perhaps we update the spec to: ``` 1. Commits MUST be prefixed with a type, which consists of a noun, feat, fix, etc., followed by a colon and a space (types are not case sensitive). ``` @stevemao ☝️would this require sweeping changes to the parser?

GiteaMirror commented

2026-02-17 11:39:49 -06:00

@zeke commented on GitHub (Feb 18, 2019):

I'd still lean toward a lowercase requirement, but that doesn't seem to be the popular opinion here.

semantic-release requires lowercase prefixes, so if the final decision for the spec is to remain case insensitive , I may have to make https://github.com/probot/semantic-pull-requests deviate slightly from the spec to maintain compatibility with semantic-release.

@zeke commented on GitHub (Feb 18, 2019): I'd still lean toward a lowercase requirement, but that doesn't seem to be the popular opinion here. `semantic-release` requires lowercase prefixes, so if the final decision for the spec is to remain case _insensitive_ , I may have to make https://github.com/probot/semantic-pull-requests deviate slightly from the spec to maintain compatibility with `semantic-release`.

GiteaMirror commented

2026-02-17 11:39:49 -06:00

@tunnckoCore commented on GitHub (Feb 18, 2019):

@bcoe: do we not care about case sensitivity, with the exception of "BREAKING CHANGE" being all upper case?

Exactly.

I don't think spec should care and it should be lite/easy on that (so, insensitive). Tools and authors on top of it can decide whatever they want as with the case with semantic-release. :) That's why I made it (parse-commit-message) insensitive too, because I'm lower-level tool/package.

That way @zeke's semantic-pull-requests won't "deviate slightly from the spec" - it still will be spec compliant. :) So, win-win.

@tunnckoCore commented on GitHub (Feb 18, 2019): > @bcoe: do we not care about case sensitivity, with the exception of "BREAKING CHANGE" being all upper case? Exactly. I don't think spec should care and it should be lite/easy on that (so, insensitive). Tools and authors on top of it can decide whatever they want as with the case with `semantic-release`. :) That's why I made it (`parse-commit-message`) insensitive too, because I'm lower-level tool/package. That way @zeke's `semantic-pull-requests` _won't_ "deviate slightly from the spec" - it still will be spec compliant. :) So, win-win.

GiteaMirror commented

2026-02-17 11:39:50 -06:00

@hutson commented on GitHub (Feb 19, 2019):

@bcoe I believe the parser just relies on the convention package.

I believe some, if not all, convention packages are case insensitive.

Though, it probably doesn't matter if, say, angular required upper case, because that's their decision to make with respect to their convention. (I would love to see a @conventional-commits/conventional-changelog-config configuration package that embodies the conventions in this spec 👍 )

perhaps we update the spec to

In addition to, or in place of, the FAQ item that exists?

@hutson commented on GitHub (Feb 19, 2019): @bcoe I believe the parser just relies on the convention package. I believe some, if not all, convention packages are [case insensitive](https://github.com/conventional-changelog/conventional-changelog/blob/97ad96fe893bd5b40ec52e24fe46f4f9cd357a1a/packages/conventional-changelog-angular/parser-opts.js#L4). Though, it probably doesn't matter if, say, `angular` required upper case, because that's their decision to make with respect to their convention. (I would love to see a `@conventional-commits/conventional-changelog-config` configuration package that embodies the conventions in this spec :+1: ) > perhaps we update the spec to In addition to, or in place of, the FAQ item that exists?

GiteaMirror commented

2026-02-17 11:39:51 -06:00

@bcoe commented on GitHub (Mar 16, 2019):

@stevemao can you confirm that the toolchain is case insensitive?

@bcoe commented on GitHub (Mar 16, 2019): @stevemao can you confirm that the toolchain is case insensitive?

GiteaMirror commented

2026-02-17 11:39:51 -06:00

@bcoe commented on GitHub (Mar 16, 2019):

☝️ @stevemao if so, I suggest we add this to the specification for upstream tooling implementors.

@bcoe commented on GitHub (Mar 16, 2019): ☝️ @stevemao if so, I suggest we add this to the specification for upstream tooling implementors.

GiteaMirror commented

2026-02-17 11:39:52 -06:00

@stevemao commented on GitHub (Mar 20, 2019):

BREAKING CHANGE is, but feat, fix, etc are not ATM. It's very easy to change though.

@stevemao commented on GitHub (Mar 20, 2019): `BREAKING CHANGE` is, but `feat`, `fix`, etc are not ATM. It's very easy to change though.

GiteaMirror commented

2026-02-17 11:39:53 -06:00

@tunnckoCore commented on GitHub (Mar 20, 2019):

I think that we can add one more point - the 12 which will say something like:

"All parts of the commit message are case insensitive, except the BREAKING CHANGE one. Note that, upstream implementers of this specification MAY enforce case sensitivity for some of the parts - for example, the type to be always lowercased."

I'm all in for case insensitive in the parsers side (like my case with parse-commit-message parser), so higher level tools and users may enforce whatever they want.

@tunnckoCore commented on GitHub (Mar 20, 2019): I think that we can add one more point - the `12` which will say something like: _"All parts of the commit message are case insensitive, except the `BREAKING CHANGE` one. Note that, upstream implementers of this specification MAY enforce case sensitivity for some of the parts - for example, the type to be always lowercased."_ I'm all in for case insensitive in the parsers side (like my case with `parse-commit-message` parser), so higher level tools and users may enforce whatever they want.

GiteaMirror commented

2026-02-17 11:39:54 -06:00

@damianopetrungaro commented on GitHub (Mar 25, 2019):

I am fine with both actually.
I do not see any advantage imposing case sensibility here, exception made for the BREAKING CHANGE:.

@damianopetrungaro commented on GitHub (Mar 25, 2019): I am fine with both actually. I do not see any advantage imposing case sensibility here, exception made for the `BREAKING CHANGE:`.

GiteaMirror commented

2026-02-17 11:39:54 -06:00

@bcoe commented on GitHub (Mar 25, 2019):

we've added a stanza removing case-sensitivity from the latest revision of the spec 👍 for the record, I'm working on a conventionalcommits preset for conventional-changelog that is true to this decision:

https://github.com/conventional-changelog/conventional-changelog/pull/429

@bcoe commented on GitHub (Mar 25, 2019): we've added a stanza removing case-sensitivity from the latest revision of the spec :+1: for the record, I'm working on a conventionalcommits preset for conventional-changelog that is true to this decision: https://github.com/conventional-changelog/conventional-changelog/pull/429

GiteaMirror referenced this issue

2026-02-17 11:56:36 -06:00

[PR #54] [MERGED] v1.0.0-beta.2 spanish translation #265

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#54