> Changing the default behavior feels like a breaking change

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.

It's not that there are breaking changes, but that breaking changes were introduced in a patch release.

How is Python a disaster?

I'm not fine with breaking changes in a patch bump, otherwise it means versioning is useless

In addition to what the siblings say, in case parent isn't aware of semantic versioning: https://semver.org/

Backwards compatibility is a mainstay in Go and I don't experience bloat, and, I believe, such goals are a hallmark of good api design. Source: over the last 20 years, built several and used many large code bases that have used for years and years that had different teams and individuals regularly committing into them.

Actually this was just a stupid bug I introduced in 2.0.3 which was found soon after 2.0.3 shipped. I fixed a bug that allowed ajax api to target body and blow away your whole page in error if one of the selectors you pass in was not found. But It broke the default no source and target behavior but this is now fixed that 2.0.4 is shipped

This is why I think semver is impossible to do in practice.

Hot take, only idiots think semver has any real world proven benefit. There's a reason most major software packages don't bother with it.

> This is why I think semver is impossible to do in practice.

The semver docs explicitly address this scenario. If a change in minor update breaks compatibility release a new minor update to revert the change.

It’s correct practice, but bad luck for anyone who ends up depending on the buggy behavior in 2.0.3. Their code will break when they upgrade to (say) 2.0.7.

This would make sense if 2.0.3 was released long enough ago for people to start using and relying on a bug, but it was released less than 2 months ago...

The bug in 2.0.3 just breaks one default use case and where you pass in no source or target to the api so anyone using this feature their app broke on upgrade to 2.0.3 and they had to set a source explicitly or revert the version. 2.0.4 just fixes this with no downside unless you like seeing console errors

Agree, behavior vs misbehavior (aka feature vs bug) is user's decision (at call site), not author's decision (at implementation side).

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.

Ah okay, that makes total sense. I should have checked the PR first!

> though hopefully there weren't sites expecting an ajax call to not do anything

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")

And now your body is clobbered, leaving either nothing behind or a raw JSON response or some such thing. Seriously.

Should such a person have used fetch() instead? I dunno, probably; I don’t use htmx.

This is an extremely breaking change.

Yeah I tend to agree this should have been in a minor rather than a patch release. The reality is that I tend to regard the JavaScript api as an afterthought (the html attributes are the main api) and the existing behavior seemed like a nonsensical bug, but on reflection I wouldn’t have changed the html api like that and should treat the JavaScript api the same way.

That's fair, I guess someone could be doing that. Not quite sure why you would though, if you're already in JS and aren't updating the DOM, fetch() would make more sense.

Either way it sounds like this was a fix to a bug introduced in the last patch so the semver makes more sense here.

> though hopefully there weren't sites expecting an ajax call to not do anything.

thatsthebeautyofit.com in shambles

yeah, the htmx JavaScript API is not widely used, but I agree it's right on the edge of what's acceptable in a patch release

why would you call it expecting it to do nothing?

why is the wrong question, because it doesn't matter

of course it matters. not all workflows are worth preserving at all costs. there could be a really important trade off lurking, I'm not familiar, which is why I asked!

https://xkcd.com/1172/