What prefix to use for visual/content changes? #93

New Issue

GiteaMirror · 2026-02-17T11:45:05-06:00

GiteaMirror commented

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

Originally created by @runofthemillgeek on GitHub (Mar 13, 2020).

I have two questions here:

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.
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.

Originally created by @runofthemillgeek on GitHub (Mar 13, 2020). 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_.

GiteaMirror closed this issue

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

GiteaMirror commented

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

@damianopetrungaro commented on GitHub (Mar 15, 2020):

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 commented on GitHub (Mar 15, 2020): 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 :)

GiteaMirror commented

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

@runofthemillgeek commented on GitHub (Mar 16, 2020):

@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?

@runofthemillgeek commented on GitHub (Mar 16, 2020): @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?

GiteaMirror commented

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

@damianopetrungaro commented on GitHub (Mar 16, 2020):

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 :)

@damianopetrungaro commented on GitHub (Mar 16, 2020): 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 :)

GiteaMirror commented

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

@pushred commented on GitHub (Mar 28, 2020):

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.

@pushred commented on GitHub (Mar 28, 2020): 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.

GiteaMirror commented

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

@isotopeee commented on GitHub (Jul 1, 2020):

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.

@isotopeee commented on GitHub (Jul 1, 2020): 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.

GiteaMirror referenced this issue

2026-02-17 11:57:22 -06:00

[PR #94] [MERGED] Add bumped #283

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#93