This one jumped out to me as an interesting one for a patch release. Changing the default behavior feels like a breaking change, though hopefully there weren't sites expecting an ajax call to not do anything.
The semver docs explicitly address this scenario. If a change in minor update breaks compatibility release a new minor update to revert the change.
Semver is just _indicative_ attempt at describing changes.
If this wasn't true, we wouldn't have lockfiles.
Ie. semver is just approximate attempt at change description that aids/helps development/maintenance but should never be fully trusted.
The only way it could fully work in automated fashion is if the whole program would be written in some formal proof language – then dependency upgrades could be considered as breaking or non breaking. But again, easier and more precise from end user position, not author's position because breaking change in one project can always be non breaking in other if that part is not used/used in more relaxed manner.
It didn’t need to do nothing, it just needed to have no visible effect.
I would be absolutely astonished if this affected no one. It’s very easy to imagine someone having written
htmx.ajax("GET", "/some-tracker-that-returns-nothing-or-json-or-something")
Should such a person have used fetch() instead? I dunno, probably; I don’t use htmx.
This is an extremely breaking change.
Either way it sounds like this was a fix to a bug introduced in the last patch so the semver makes more sense here.
thatsthebeautyofit.com in shambles
I'm fine with breaking changes personally. An adherence to maintaining backward compatibility always is what leads to bloat and criticisms of "poor design" from HNers in the future.
Keep it slim, have one way to do things, and avoid the disaster that is js and python today.