How do you handle the perf: type in your software project?

[tsdtsdtsd]

The conventional commits spec states that only feat, fix, BREAKING CHANGE and ! correspond to semver changes (as it's implemented in this great tool).

Additional types like perf (code change that improves performance) are allowed, but do not bump versions.

From my POV a performance improvement (an actual code change) is something that I maybe want to release sooner than the next feature or bugfix, but I wouldn't be able get a new automated version for it.

How do you guys handle that in your projects? Forget about the existence of perfand stick to feat/fix etc.? Manually intervene and declare a new version?

Thanks in advance for your thoughts!

[mamachanko]

One could argue that a however significant increase in performance is a feature to the benefit of the user. Therefore I tend towards feat: to convey that the minor should be bumped. If it's not something the user would notice or that should not trigger a version bump then I would consider perf: to be part of the motivation for the commit itself, i.e. documentation and context for readers of the Git history.

[caarlos0]

I agree, visible performance optimizations are definitely features.