You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
For 1.0, we scaled back our ambitions in this commit: ba6fa6b
Here is what we had been planning:
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 thetypesBump
concept becauseifFound
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:
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.
The text was updated successfully, but these errors were encountered: