Validate the optional ! before : for breaking change. about semantic-pull-requests

[bcoe]

so, for the record, I think that the spec should be updated such that if ! is present, there's not need for BREAKING CHANGE; this is how I've found myself using the new functionality in the tooling I'm writing.

I've actually updated the next version of the spec to reflect this, we just haven't promoted it to the main page yet:

conventional-commits/conventionalcommits.org@df6de82

[zeke]

Ahh, right! I'm excited about this new development in the Conventional Commits spec.

I'd be happy to help support for this in semantic-pull-requests, but I think the change will probably need to be implemented in https://github.com/tunnckoCoreLabs/parse-commit-message -- I would suggest opening an issue or pull request there.

cc @tunnckoCore

GitHub

tunnckoCoreLabs/parse-commit-message

Parse, stringify or validate a commit messages that follows Conventional Commits Specification - tunnckoCoreLabs/parse-commit-message

[tunnckoCore]

Ahh, right, thanks for pinging me.

If I'm honest I definitely don't like this spec addition. When it was merged? Where it was discussed? Can you give me some links, I clearly missed that ;/

Yes, it will probably be a small change. It's here.

edit: Actually, this text forces me to do a bit more there. TO detect if there is ! and then check and validate if there's also BREAKING CHANGE in the body. It just complicates the things a bit and clearly don't like it.

[zeke]

When it was merged? Where it was discussed? Can you give me some links

• conventional-commits/conventionalcommits.org#134
• conventional-commits/conventionalcommits.org#152
• https://www.conventionalcommits.org/en/v1.0.0-beta.4/#commit-message-with-optional-to-draw-attention-to-breaking-change

The reason I like this change is that it paves the way to a future where people don't have to write BREAKING CHANGE in the commit body to signal a breaking change. This will make it easier for newcomers to start adhering to the spec, as most people always write single-line commit messages, and hardly anyone uses the "body" when committing.

Conventional Commits

Conventional Commits

A specification for adding human and machine readable meaning to commit messages

[tunnckoCore]

I totally disagree with that. Specs are not to be easy for newcomers, they are up there for combining and standardizing the things among the biggest part of a community - in this case, us the developers which have experience and we are not newcomers. Also, currently it's pretty clear and easy enough - type, scope, subject, body.

And yes, I agree and understand that most of us don't use the body when committing, even more we don't put scope most of the time. But breaking change is something that should be carefully done and hard to do, that's one point why it's uppercased.

If we are going to do it simple why just don't remove everything and just make the spec to handle only the header part. Specific attention to writing the BREAKING CHANGE part is the best thing of the spec. Not to mention that ! is a single character and no that easy to be seen.

paves the way to a future where people don't have to write BREAKING CHANGE in the commit body to signal a breaking change

If that gets agreed I'll stop updating the parser to adhere to the spec. I can update it now just because both ! and BREAKING CHANGE are required now (from what I'm understanding from the spec).

I'll look at the discussions.

[tunnckoCore]

I'm heading to the parser in coming days too.

[tunnckoCore]

Erm... @zeke, hi, do you remember where we were using and commenting the very latest updates? The 4.0.0-canary.20 is the last version in the canary branch. Sadly enough, I can't remember/find from where I published it. There's only a "dist" copy in npm and unpkg :D

Oooh, sorry, it's here #75

[zeke]

This issue is old and inactive so I'm going to close it. If anyone is still affected by this, let me know and I'll re-open it.