Semantic Versioning, maybe more care is needed? #2574
-
From the CHANGELOG of version 1.13.5, a patch level increment (emphasis mine):
To my understanding of SemVer, shouldn't that constitute a major version increment? Why is this an issue? Because a patch level change broke my tests even though I only relied on the public API. I was using it to verify that incoming HTML had properly escaped I understand why the change was made, and I can appreciate that it was libxml2 in this case, but since it was actually noted in the changelog, I do want to urge you to actually bump the major version when you know you're making breaking changes. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Thanks for bringing this up, and sorry you experienced this problem. I've written about SemVer often enough that it now has its own section in the README (note in particular that "security updates" falls under "patch release"): https://github.com/sparklemotion/nokogiri/blob/main/README.md#semantic-versioning-policy Nokogiri is a thin-as-possible wrapper around libxml2. You can build Nokogiri against your system distro's version of libxml2, and in fact for many years this was the only way to use Nokogiri. With that perspective, libxml2 can upgrade independently of Nokogiri and so it's hard to justify a major (or even a minor) version bump when Nokogiri is simply adapted to work with that new version. More specifically, though, I will point out that the original libxml 2.9.13 behavior was even more broken, and we reverted it in Nokogiri's distro and lobbied successfully upstream to have that change reverted and fixed. This was a security and performance issue related to how broken markup is parsed and made safe for downstream consumption. It does not make sense to me to hide it behind a major version bump, particularly because there was no API change that required any callers to change their code. It's possible that we simply will not agree on the definition of what justifies a major or minor version bump, I think that's OK so long as the release policy is clear, and the maintainers are being consistent in how this policy is applied (and I think these statements are true for Nokogiri). If the behavior described is, in your opinion, breaking-enough of a change to violate SemVer, I'd ask that you lobby upstream to the libxml2 maintainers. I believe I made the right decision here, but again we may disagree and that's OK with me so long as the policy sets clear expectations and is followed. |
Beta Was this translation helpful? Give feedback.
Thanks for bringing this up, and sorry you experienced this problem. I've written about SemVer often enough that it now has its own section in the README (note in particular that "security updates" falls under "patch release"):
https://github.com/sparklemotion/nokogiri/blob/main/README.md#semantic-versioning-policy
Nokogiri is a thin-as-possible wrapper around libxml2. You can build Nokogiri against your system distro's version of libxml2, and in fact for many years this was the only way to use Nokogiri. With that perspective, libxml2 can upgrade independently of Nokogiri and so it's hard to justify a major (or even a minor) version bump when Nokogiri is simply adapted to work with that n…