How to classify UI change according to the conventional commits specification?

Question

Based on the conventional commits how are mere UI changes supposed to be classified? For example suppose a logout button is moved from the bottom of the screen to the top, an icon is added next to the text, and there is a new animation. Other then that nothing changes from a functional perspective.

My confusion comes from this (probably wrong) reasoning. You can't use any of the following because:

• feat: it's not a new feature
• fix: there isn't any bug to fix
• perf: performance is not touched upon
• refactor: this could be the case following the Angular definition of refactor "A code change that neither fixes a bug nor adds a feature", but not using the Wikipedia definition of refactor "code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior"
• style: changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc). It's self evident that this isn't the case

Answer 1

A feature does not need to be very big. Despite the code change being very small, the relocation of the log out link is user-facing, and thus is a feature. Using the "feat" prefix for your commit is acceptable.

feat: moved logout link to top of page, resolves #1234

On the other hand, if the log out link was never supposed to be at the bottom, and moving it to the top corrected that, then use "fix:" before your message.

fix: moved logout link to top of page. Fixes #1234

The article you link to mentions quite a bit about semantic versioning, and seems to be geared more towards APIs rather than entire applications, so exact translations to application changes will not exist, but you can make some correlations.

Answer 2

The mission statement for the Conventional Commits specification is:

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

Other tools can then use that specification to work out whether a changeset warrants a release or not.

However none of this is meant to know what you're releasing or whether you intended to release at all.

For example some of these tools won't release a changeset that contains only docs or style type commits. After all a change in the documentation of a private function or converting tabs to space doesn't really impact your end users. Therefore that changeset will be shipped in a release next time you produce a "meaningful" commit.

However as with pretty much everything, context is key:

• In a NPM library, a README file is always part of the package. If there's a factual error or something missing, you probably want to deliver that change as soon as possible. So a docs type commit probably isn't appropriate here. Perhaps this is more of a fix?

• In a Git-managed blog, a whitespace-only change may actually improve the readability of your content. Would a feat type commit be a better fit here?

Why are you making that change?

As I tried to illustrate above, context is important. Don't take the examples that you saw at their face value.

• Are you making that change because the UI/UX guidelines of your company are changing? This would be a feat type commit IMHO. (And possibly a breaking change?)

• Are you making that change because an A/B test has shown that this would be the best change for your product or your users? This would be a feat type commit again IMHO.

• Are you making that change because a user has lodged a complaint that they couldn't see where to sign out of your app? This may be more of a fix type commit.