61–70 of 294 posts
The use of the word "chore" in many users of conventional commits has always riled me. I've always tended to favour the "linux kernel"[0] style of commit subject, which thankfully gets a mention here. [0] https://www.kernel.org/doc/html/v7.0/process/submitting-patc...
I quite dislike this style of writing titles. "Stop something". I seems very popular. It sounds very commanding and "I am definitely right about this". Why not write "In favour of something" or "A case against something" or something like that?
I don't like conventional commits much neither, but let the people use whatever they want!
I quite dislike this style of writing titles. "Stop something". I seems very popular. It sounds very commanding and "I am definitely right about this". Why not write "In favour of something" or "A case against something" or something like that?
The author's example of a conventional commit is not correct anyway IMO, which is maybe why they think the "fix" part is redundant: > fix: prevent foo from bar'ing The whole idea of conventional commit is: > fix: [problem] so the correct conventional commit would be: > fix: foo bar'ing which is succinct and perfectly fine.
The use of the word "chore" in many users of conventional commits has always riled me. I've always tended to favour the "linux kernel"[0] style of commit subject, which thankfully gets a mention here. [0] https://www.kernel.org/doc/html/v7.0/process/submitting-patc...
There’s a much less awkward way to keep a change log: Keep a change log.
Could/should the changelog be considered a first-class deliverable with care and attention provided? I think so, but I'm not in a position to exert direct control over that across dozens of repos and team members.
The use of the word "chore" in many users of conventional commits has always riled me. I've always tended to favour the "linux kernel"[0] style of commit subject, which thankfully gets a mention here. [0] https://www.kernel.org/doc/html/v7.0/process/submitting-patc...
Same idea without the pejorative aspect.
Earlier quoted context omitted.
The article is wrong about reverts (in my opinion). If a breaking change is introduced, and then removed, the removal should also most likely be considered a breaking change (both the addition and removal are changing your API). So it is correct that a major version bump should occur when reverting. Once a package has been published, the ship has sailed.
The issue is that if there was no release in between, or only a beta or similar, you now have two breaking changes indicated by the commits, although in sum there is none since the last official release.
If you are releasing upon every push to main/master (following what semantic release and conventional commits provides you in terms of automation), then it makes sense to perform major version bumps for the reverts.
If you have a manual release strategy, then it might not make sense to use these tools in the way they have been designed.
The use of the word "chore" in many users of conventional commits has always riled me. I've always tended to favour the "linux kernel"[0] style of commit subject, which thankfully gets a mention here. [0] https://www.kernel.org/doc/html/v7.0/process/submitting-patc...
You might enjoy Rich's take: https://richvdh.org/conventional-commits-considered-harmful....