chore(renovate): update semantic commit types in configuration

[bircni]

For vulnerability alerts it makes sense to keep fix since those are actual security fixes but for others a dependency update is a chore

[bircni]

depending on #37659 otherwise ci will still fail

[wxiaoguang]

This problem is still not resolved: how to handle the "enhancement" label for PRs?

• feat(editor): broaden language detection in web code editor #37619 (comment)

[silverwind]

This is already the default, but I guess it's ok to spell it out again explicitely.

[silverwind]

This problem is still not resolved: how to handle the "enhancement" label for PRs?

I'd keep them at feat until a new changelog generator is added that supports enhancement. Will need a new generator in any case before 1.27 release.

[wxiaoguang]

This problem is still not resolved: how to handle the "enhancement" label for PRs?

I'd keep them at feat until a new changelog generator is added that supports enhancement. Will need a new generator in any case before 1.27 release.

Sorry it's unclear to me.

1. Should the "enhancement" label be used?
   • If yes: when to use it?
   • If no, should it be removed?
     • If yes: when & how to remove?
     • If no: why keep it? how to tell people "don't use it"?

[silverwind]

Just remove it in a future label cleanup. It comes from the default GitHub labels which don't fit in a semantic commit scheme. Same goes for type/bug etc, basically all label that previously categorized PRs.

[lunny]

This problem is still not resolved: how to handle the "enhancement" label for PRs?

I'd keep them at feat until a new changelog generator is added that supports enhancement. Will need a new generator in any case before 1.27 release.

What did you mean for that? https://github.com/go-gitea/gitea/blob/main/.changelog.yml#L26

[silverwind]

We've been merging semantic commits since a while now, most PRs are unlabeled because of that. v1.27 release will require a bit of manual categorizing, v1.28 release can be created full off the commit titles alone.

[wxiaoguang]

We've been merging semantic commits since a while now, most PRs are unlabeled because of that. v1.27 release will require a bit of manual categorizing, v1.28 release can be created full off the commit titles alone.

I am not in the "we"

Actually I have objection of "removing enhancement label"

The design should be like this in my mind:

• Big improvements to end users: feature
• Trivial: enhancement (for example: text change, color change, padding change, etc)

But I won't block your decision if most people prefer yours.

[silverwind]

In essense this change is almost a noop:

• semanticCommitType is redundant, it is the default and individual updates can still trigger other types like fix
• vulnerabilityAlerts.semanticCommitType forces the fix type even for non-fixes. Theoretically it is possible that renovate raises a security update as chore, practically they are almost always fix, but I could see low-score vulns be flagged as chore.

So I think it's actually a slight degradation in functionality and it's better to keep the defaults as-is.

[wxiaoguang]

@bircni

What's your decision to these?

• chore(renovate): update semantic commit types in configuration #37658 (comment)
• chore(renovate): update semantic commit types in configuration #37658 (comment)
• chore(renovate): update semantic commit types in configuration #37658 (comment)

And what's the decision of TOC?

[bircni]

@bircni

What's your decision to these?

• chore(renovate): update semantic commit types in configuration #37658 (comment)
• chore(renovate): update semantic commit types in configuration #37658 (comment)
• chore(renovate): update semantic commit types in configuration #37658 (comment)

And what's the decision of TOC?

I suggest the following:

• build: Changes that affect the build system or external dependencies (dependency updates)
• ci: Changes to CI configuration files and scripts
• chore: Changes which doesn't change source code or shall NOT be included in the Changelog
• docs: Documentation only changes
• feat: A new feature
• fix: A bug fix or a dependency bump which fixes security
• refactor: A code change that neither fixes a bug nor adds a feature
• revert: Revert something
• style: Changes that do not affect the meaning of the code (lint)
• test: Adding missing tests or correcting existing tests

• A feat! indicates a breaking change

2 nice useful things pop out here:

1. we can label according to the Pr message to make it easier to filter
2. we can generate changelog from it in an easy way, maybe using git-cliff

---

Comments:

• refactor: A code change that neither fixes a bug nor adds a feature

--> Here I would put an enhancement in or other option is to use enh which is not that good I think

[wxiaoguang]

2 nice useful things pop out here:
1. we can label according to the Pr message to make it easier to filter
2. we can generate changelog from it in an easy way, maybe using git-cliff

Then I guess you mean "remove the enhancement label" is the answer to #37658 (comment) , right? If so, what are the plan & steps for the removal?

[bircni]

2 nice useful things pop out here:

1. we can label according to the Pr message to make it easier to filter
2. we can generate changelog from it in an easy way, maybe using git-cliff

Then I guess you mean "remove the enhancement label" is the answer to #37658 (comment) , right? If so, what are the plan & steps for the removal?

I'd suggest I open a new branch with the changes then TOC and whoever approves or discusses there
--> this here can be closed

[wxiaoguang]

And some real examples, what kinds of these PRs should be?

• Allow text selection on checkbox labels (Allow text selection on checkbox labels #36970)
  • IMO no style change, not really a feature, so "chore"?
• Use "Enable Gravatar" but not "Disable" (Use "Enable Gravatar" but not "Disable" #36771)
  • IMO not a bug fix, doens't really fit "refactor", useful to end users, but not really a feature
• Add paging headers (Add paging headers #36521)
  • Not bug, not chore, not refactor
• Disable matchBrackets in monaco (Disable matchBrackets in monaco #36089)
• Add placeholder content for empty content page (Add placeholder content for empty content page #37114)
  • Only add some dummy elements, style? I don't think so.

I think they fit "#37658 (comment)"

Trivial: enhancement (for example: text change, color change, padding change, etc)

---

I'd suggest I open a new branch with the changes then TOC and whoever approves or discusses there
--> this here can be closed

Agree

[bircni]

And some real examples, what kinds of these PRs should be?

• Allow text selection on checkbox labels (Allow text selection on checkbox labels #36970)

  • IMO no style change, not really a feature, so "chore"?

User-facing behavior improvement. --> fix

• Use "Enable Gravatar" but not "Disable" (Use "Enable Gravatar" but not "Disable" #36771)

  • IMO not a bug fix, doens't really fit "refactor", useful to end users, but not really a feature

UX/text consistency correction. --> fix

• Add paging headers (Add paging headers #36521)

  • Not bug, not chore, not refactor

Adds externally consumable functionality/API capability. --> feat

• Disable matchBrackets in monaco (Disable matchBrackets in monaco #36089)

Adjusts broken/undesired editor behavior. --> fix

• Add placeholder content for empty content page (Add placeholder content for empty content page #37114)

  • Only add some dummy elements, style? I don't think so.

--> purely a UX enhancement --> feat

---

but yes overall an "enhancement" is better - let me try

[wxiaoguang]

Well, I am not convinced.

The current "label" system works like this:

• "bug (fix)": need to be backported to stable release (unless it is difficult to backport)
• "feature": can be highlighted to end users in release log
• "enhancement": trivial fix or improvement, usually no need to be backported (can be backported if simple enough), appear in changelog but no need to highlight to end users.

If every "enhancment" becomes "feature", end users just are not able to find the real new features.

[lunny]

I also think we need an enhancement label in addition to feature. Sometimes a small improvement to the UI or an existing feature fits better under enhancement. It doesn’t mean the previous implementation was wrong, only that the new implementation is an improvement.

We could also add a highlight label, so that important features, enhancements even performance changes can be marked and tracked separately.

I will always label a PR when possible. It doesn't take more than 1 second.

[techknowlogick]

+1 for keeping enhancement. @wxiaoguang the way you described the current state is also my understanding, and I agree with your conclusion that if every non-bugfix becomes "feature" then it's hard to find the actual new features.

[bircni]

Started here

#37677