conventionalcommits.org

conventionalcommits.org copied to clipboard

I have two questions here:

1. For content changes that involves purely the change in text/i18n texts, what prefix makes sense? Such changes, IMO, shouldn't warrant "feat". The closest I've seen is "docs" but um, that doesn't seem logical.
2. For style changes (e.g. color, font-size etc.), does it count as "feat"? I used to initially confuse "style" with such changes but realized later that it concerned the style of the code.

It depends on the point of view of the commit.

If the change introduced, for example, new language support to the i18n then it'd be a feat, otherwise, it may also be a fix if there's typo.

And the same principle is valid fot rhe second one as well :)

@damianopetrungaro Understand how it can be a feat for i18n changes but if it's merely copy change that involves say a tone change and if I'm using tools like semantic release, that'd mean a major version bump and I think that's a little too much. What are your thoughts on that?

You may also use improvement as type. But from my point of view it is fix/feat or chore if it is not code related :)

Personally I use refactor from the Angular convention types for these changes. Since they are purely visual and lingual in nature they don't affect feat if they are changes to something that already exists. If there's an accessibility issue or a typo, fix can be warranted. Otherwise it's just iteration similar to code refactoring. It's a change but it doesn't affect functionality.

Thanks @sangeeth96 for raising this issue. I'm confused about this too. I intermittently use chore and refactor too, but I guess refactor makes more sense for both cases.