Description
For 1.0, we scaled back our ambitions in this commit: ba6fa6b
Here is what we had been planning:
spotlessChangelog {
types ['Added', 'Changed', 'Deprecated', 'Removed', 'Fixed', 'Security']
typesBumpMinor ['Added']
typesBumpMajor ['Changed', 'Removed']
}I think a simple regex for minor and major version turns out to be easier to understand and works better than the type categories above. After all you can say ifFoundBumpMajor '### Changed', '### Removed' to get the same effect, so I'm against the typesBump concept because ifFound is strictly better.
Enforcing the spelling, set, and order of the tags seems useful, but only if it's not annoying. If it complains about the order but can't fix it with changelogApply, then that would be annoying.
Implementing this is very low-priority for us, but if anyone wants it for themselves, here is a test case it would need to pass:
## [Unreleased]
## [2.0.0] - yyyy-mm-dd
This release has a lot of breaking changes, but the reason is blah blah blah
### Added
...
### Removed
- some widget
<sup>1</sup> details on something from the addition block
<sup>2</sup> more details
## [1.0.0] - yyyy-mm-dd
It doesn't need to enforce the ordering, but if it does, it has to be able to reorder them too. If it's not implemented carefully, that reordering could be destructive, so you'll need to be careful and prove that the reordering is careful to get it merged.