search

jmongard / Git.SemVersioning.Gradle

Gradle plugin for automatically versioning a project using semantic versioning and conventional commits with change log support based on git commit messages.
https://plugins.gradle.org/plugin/com.github.jmongard.git-semver-plugin
Apache License 2.0
38 stars 4 forks source link

Make the order of changelog entries configurable #36

Closed sschuberth closed 4 months ago

sschuberth commented 9 months ago

Sometimes it's desirable to list more important changes (like breaking changes) first, before less important changes (like chroes). As such it would be nice to have control over the order of the header sections in the changelog. The easiest way to achieve this would probably be to simply maintain the order of the key in the headerTexts map. As mutableMapOf() creates a LinkedHashMap which maintains insertion-order, that should work.

jmongard commented 9 months ago

Yes,

Currently the headings is sorted alphabetically (which coincidentally puts breaking changes at the top).

Would maintaining order from commit order rely make sense or would a rang on the headings be better?

sschuberth commented 9 months ago

The easiest way to achieve this would probably be to simply maintain the order of the key in the headerTexts map.

Turns out that's no a good idea as it wouldn't allow to also specific the ordering for breakingChangeHeader, otherChangeHeader and missingTypeHeader.

sschuberth commented 9 months ago

And frankly, before introducing something like an order key for all those headers, I'm again coming back to the more general https://github.com/jmongard/Git.SemVersioning.Gradle/issues/28 which would also allow to solve this.

jmongard commented 4 months ago

I added a list property to the ChangeLogTexts that list types that should be presented first in the change log (after breaking changes) and initialized it to [fix, feat]. This would make it easier to configure the order of the entries. Do you have any other ide or should I close this?

sschuberth commented 4 months ago

Any specific reason why e1cc17c60e600f22a879f594eeaaa44683691960 still hard-codes breaking changes to go first? Why are not all types allowed in typesOrder? Not that I personally would want breaking changes not to go first, but the way it is the feature seems only half-implemented.

jmongard commented 4 months ago

Yes, the reason is that I think it is preferable the braking changes is presented first and that breaking changes can be of any type. The change log formatter works by "consuming" the entries from the list of entries so the breaking changes would not end up together.

There is also the possibility to just use any template you want and move the breaking change where you want. I don't believe that many would create their own format from scratch but adding some strings to a list could be easy enough.

sschuberth commented 4 months ago

Ok, I believe that's good enough then, so let's close this.