diffplug / diffplug/spotless-changelog
Enforce "types" of changes
- Dominant language
- Java
- Stars
- 49
- Forks
- 2
- PR merge metrics
- No merged PRs in 30d
Description
For 1.0, we scaled back our ambitions in this commit: ba6fa6bf63ae83ee24407cad4c5dbbfa3f5d79ce
Here is what we had been planning:
```gradle
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
1 details on something from the addition block
2 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.
Contributor guide
Assessment
This issue has not been assessed yet.