Sort commits by scope within changelog categories

[alpha0010]

Description

Changelog generation already separates commits by change type, but within each category, messages are produced in commit order. It would be nice to have an output format to sort messages alphabetically and/or group by scope.

Possible Solution

Current output:

### Fix

- **annotation**: render loses detail
- **android**: crash on invalid page count
- **meter**: parse fails to detect most meters
- handle footer line breaks
- **android**: support native dependency configuration
- **annotation**: text positioning and dot strokes

Desired option 1:

### Fix

- handle footer line breaks

#### Android

- crash on invalid page count
- support native dependency configuration

#### Annotation

- render loses detail
- text positioning and dot strokes

#### Meter

- parse fails to detect most meters

Desired option 2:

### Fix

- **android**: crash on invalid page count
- **android**: support native dependency configuration
- **annotation**: render loses detail
- **annotation**: text positioning and dot strokes
- **meter**: parse fails to detect most meters
- handle footer line breaks

From client side, I could implement this via changelog_hook(). However, that requires re-parsing the already parsed and formatted data. I could additionally hack changelog_message_builder_hook() to set message as JSON string, to later parse in changelog_hook().

Is there a cleaner way to handle this?

Additional context

No response

Additional context

No response

[Lee-W]

I like this feature. I don't think we have a cleaner way to achieve it. @woile any thought?

[woile]

I think ordering by scope wouldn't add much overhead and it would be a nice feature to have

[yajo]

I'd appreciate some configurability. In my case, I prefer to keep them time-ordered, but contrary to how they are now. Right now, most recent commits appear on top, and older commits appear below. I think it's more natural to make it the other way around: start with the oldest and continue with the newer. This way, reading the change log is like seeing how the project evolved in that time. It's possible that, in the same release cycle, one fix fixes some regression that came for some other change, so keeping them sorted by oldest to newest would make this reading more natural.