undefined

points

[-]

The article is wrong about reverts (in my opinion). If a breaking change is introduced, and then removed, the removal should also most likely be considered a breaking change (both the addition and removal are changing your API). So it is correct that a major version bump should occur when reverting. Once a package has been published, the ship has sailed.

by layer82 hours ago|

parent|

[-]

The issue is that if there was no release in between, or only a beta or similar, you now have two breaking changes indicated by the commits, although in sum there is none since the last official release.

by beart2 hours ago|

parent|

[-]

That's true, but depends on your workflow and release strategy.

If you are releasing upon every push to main/master (following what semantic release and conventional commits provides you in terms of automation), then it makes sense to perform major version bumps for the reverts.

If you have a manual release strategy, then it might not make sense to use these tools in the way they have been designed.

by layer82 hours ago|

parent|

[-]

If you have actual dependents in a SemVer fashion, then this isn’t useful for those still on the prior version. What you’d rather do is decrement the major version again because it’s compatible with the prior version again. Those dependents who already upgraded to the interim version have to consider another breaking change regardless.

And if you don’t have these kinds of dependents, then the versioning scheme isn’t important anyway.

by claytonjy1 hours ago|

parent|

[-]

release-please[0] allows you to do a manual version override in a commit, which would allow you to decrement the major version upon reverting a breaking change

I think that could be simplified, so the tool can tell that a commit is reverting a breaking change and thus the version should be decremented, but at least there's an escape hatch.

[0]: https://github.com/googleapis/release-please

by Benjamin_Dobell2 hours ago|

prev|

[-]

My apologies, I missed this on first read due to the indentation style. That said, I don't agree on the commentary.

Why on Earth are people not writing commit messages for their reverts? They should have semantic commit messages just the same as any other commit.

Unless the point is that they're not following per-commit CD, and if you commit then revert that commit before a release was made. That sounds like a process failure. Which of course, process isn't infallible, and neither is the automated version management. If you screw up, use an escape hatch — just like reverting a commit that had previously gone through code review and been merged.

Re: change log generation. The article says change logs shouldn't have commit messages. I agree. Many tools (e.g. Changesets https://github.com/changesets/changesets) use the semantic commit type to sort change log entries, but require you to write those user facing change log entries separately.