"positive" fixed section

[KUGA2]

My collegue just fixed a bug and did something like this:

## [1.0.2]

### Changed

- product supports featureB
- product supports featureC

### Fixed

- #72983 - featureA does not work

He simply used the tickets title for the description of #72983.

So i wondered:
Whis is the Changed section "positive", meaning this is the new state of the code. But in Fixed is is "negative". It is no longer this way in 1.0.2. This seems a little odd.

--> I think we should add a rule to the guideline, that states every description must reflect the current state of the software:

## [1.0.2]

### Changed

- product supports featureB
- product supports featureC

### Fixed

- #72983 - featureA is working correctly

What do you think?

[stuzer05]

Fixes are kind of different notes. They must explicitly say what has been fixed. Usually, there is serious attention to fixes, especially security ones. And they must, sort of, cover the past.

[holistic-developer]

What really is the difference between fixed and changed?
I think about it this way:
Changed lists modifications because of changes in requirements. E.g.: This thing was working but now it should behave differently.

Whereas fixed lists changes that lead to the fulfillment of requirements which were already in place.

I agree with you to stay positive in the changelog and focus on the version at hand.
What already existing requirement is now fulfilled due to the changes in this version?
E.g.:
"Feature A (now) supports greek letters as input."
Instead of: "Feature A does not crash on greek letters"
(Although i would accept the latter as well as it still tells what is fixed instead of what is broken)
The issue number is probably more important in practice than the grammar of that sentence.

PS:
"product supports feature A"
If it could not do this before and is now fulfilling a new requirement this should be under Added.

[majormoses]

I don't see a need and this overly complicates the spec. IMO Changelogs are about intention and impact. Bugs are Fixed unless they are breaking compatibility, enhancements are Added. I think this is a case of needing to follow the KISS Principle, changelogs should be focused on consumers of the project rather than the developers or project managers.

In my opinion we do need enhancements to the spec but there should be minimal and for a very good reason, this is to avoid explosion and no one being able to rationalize how a change is classified. It is already hard enough.

I view Changes is a catch all for any updates to existing software that are not otherwise classified.

Fixed has a specific meaning, the software was intended to work one way and is not. If you consider existing behavior or lack of feature to not be a requirement when designing the system, then this falls under the enhancement category which is covered via Added. If its not expected then its a bug and therefore Fixed or Breaking Change(s) (if it loses compatibility with previous versions). In my experience maintaining large open source projects people will get annoyed if you treat bug fixes as features because this inherently breaks the contract and they wonder when your gonna break the contract in a way that crashes their systems. Anything that obscures risk to my system when evaluating changes erodes my confidence that the developers are actually following semver in the first place.