Hacker News new | ask | show | jobs
by latent22 551 days ago
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
2 comments
ahoka 551 days ago
This is why I think semver is impossible to do in practice.
link
teruakohatu 551 days ago
> 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.

link
foldr 551 days ago
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.
link
joshmanders 550 days ago
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...
link
latent22 550 days 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
link
mirekrusin 551 days ago
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.

link
_heimdall 551 days ago
Ah okay, that makes total sense. I should have checked the PR first!
link