Question: what about entries that are focused on performance?

[jokeyrhyme]

Hypothetically, what if you had an entries like:

• method() now uses 50% of the memory
• on a 2012 MacBook, method() completes in 30% of the previous elapsed time

Are these fixes? Or additions? Should there be a new performance section?

[masukomi]

Two things:
I would suggest that "method() does x" is generally too detailed for a change log. A change log entry shouldn't be that tied to the implementation (personal opinion of course). You want it to be something you can give to end users not people deep in the weeds. For example:

• Reduced memory usage in core method(s)
• Reduced run time by 30% on 2012 MacBooks

The doc specifies an "added", "changed", and "removed" section. What you've proposed is neither adding, nor removing, and it's absolutely a change... so "changed" is where it goes. I see no reason that doesn't adequately contain performance changes.

[olivierlacan]

I think I agree with @masukomi.

Just think of it as changed X to improve performance.

Therefore:

### Changed
- Reduced memory usage in core method(s)
- Reduced run time by 30% on 2012 MacBooks

The only exception in the guidelines is "Security" because those changes should stand out dramatically. Performance improvements are nice to have, but I think it's a bad idea to dilute attention with one more sub-section when really performance improvements can fit in either: Added, Changed, Fixed, or Removed.

[jokeyrhyme]

Sounds good. Changed it is!

[matteoolivi]

Overlapping (perhaps duplicate) discussion: #333 .

@olivierlacan I see your point that a standalone performance section might be an overkill. Not sure if it changes your mind (I'm undecided too), but I think you're being optimistic in considering only performance improvements. Those are nice to have, but performance regressions are more important to signal in my opinion.