proposal: UI as new type #224

New Issue

GiteaMirror · 2026-02-17T11:54:44-06:00

GiteaMirror commented

2026-02-17 11:54:44 -06:00

Originally created by @rbalet on GitHub (Apr 10, 2025).

Description

Actually, a unique change in a ui may have a ugh impact in what users take as changes, but they may not be technically counted as "feature" as they may only change the aspect of a feature, without adding, changing nor removing anything.

Example

Let say we change button borders width from 1px to 2px to make it more visible.
It should be part of the versioning, as this is quite an important change for the user, but this cannot be describe by any existing type I'm aware of.

Note

If anybody have an idea of what to be used instead, I would be glad to hear

This would solve:

Following stackoverflow question
Following issue as UI could be related to a11n

Originally created by @rbalet on GitHub (Apr 10, 2025). ## Description Actually, a unique change in a ui may have a ugh impact in what users take as changes, but they may not be technically counted as "feature" as they may only change the aspect of a feature, without adding, changing nor removing anything. ### Example Let say we change button borders width from 1px to 2px to make it more visible. It should be part of the versioning, as this is quite an important change for the user, but this cannot be describe by any existing type I'm aware of. ### Note If anybody have an idea of what to be used instead, I would be glad to hear This would solve: - [Following stackoverflow question](https://stackoverflow.com/questions/64290635/how-to-classify-ui-change-according-to-the-conventional-commits-specification) - [Following issue](https://github.com/conventional-commits/conventionalcommits.org/issues/577) as UI could be related to a11n

GiteaMirror closed this issue

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

GiteaMirror commented

2026-02-17 11:54:46 -06:00

@Kimhooo commented on GitHub (Apr 17, 2025):

I think it depends on what your code change is，if your just change 1px to 2px and don't effect the feature or meaning，you should use style: prefix ，but if your changelog is like fix button clickable area，then you may use the fix: prefix. this can help the code reviewer quickly identify the important changes.

@Kimhooo commented on GitHub (Apr 17, 2025): I think it depends on what your code change is，if your just change 1px to 2px and don't effect the feature or meaning，you should use `style: ` prefix ，but if your changelog is like fix button clickable area，then you may use the `fix: ` prefix. this can help the code reviewer quickly identify the important changes.

GiteaMirror commented

2026-02-17 11:54:47 -06:00

@rbalet commented on GitHub (Apr 17, 2025):

Hey @Kimhooo , thx for jumping on.

I'm actually using the style: as found it to be fitting.
But when I red the spec, style should be

style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)

So that isn't really ment for the style, in the meaning of UI.
But maybe I'm missunderstanding it

@rbalet commented on GitHub (Apr 17, 2025): Hey @Kimhooo , thx for jumping on. I'm actually using the `style:` as found it to be fitting. But when I red the spec, `style` should be - style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) So that isn't really ment for the style, in the meaning of UI. But maybe I'm missunderstanding it

GiteaMirror commented

2026-02-17 11:54:48 -06:00

@rbalet commented on GitHub (Apr 24, 2025):

Closing this issue as UI is already covered by style

@rbalet commented on GitHub (Apr 24, 2025): Closing this issue as `UI` is already covered by `style`

GiteaMirror referenced this issue

2026-02-17 12:00:58 -06:00

[PR #224] [MERGED] fix(ru): fix russian translation typos #372

GiteaMirror referenced this issue

2026-04-11 07:26:53 -05:00

[PR #224] [MERGED] fix(ru): fix russian translation typos #1031

GiteaMirror referenced this issue