Request for SemVer Adherence in Future Releases

[marcesdan]

Hi

I hope this message finds you well. I wanted to bring to your attention an issue that we encountered with the recent release, 1.10.0. It seems to have introduced a dependency on a higher version of Node.js, which has caused disruptions in our pipeline.

Upon reviewing the changes made in the release, it appears that a major version increment (2.0.0) might have been more appropriate, given the backward-incompatible change introduced with the new Node.js version requirement.

As a user of your project, I understand that maintaining version compatibility can be challenging, and I appreciate the effort you put into improving the software. However, adhering to Semantic Versioning (SemVer) guidelines is crucial for users to anticipate and manage potential breaking changes.

I kindly request that, moving forward, you consider following SemVer principles more closely, especially when making changes that impact compatibility. This will greatly assist users in planning for and migrating to new versions without unexpected disruptions.

If there are specific reasons for choosing a different versioning approach in this instance, I'd appreciate any insights you can provide to help us better understand the decision.

Thank you for your attention to this matter, and I look forward to your insights on the issue.

Best regards

[kkomelin]

Hi @marcesdan ,

Thank you very much for such a thoughtful request and sorry for causing issues with your build pipelines!

I totally agree that the SemVer approach would be very nice to follow but let me quote our readme:

Please note that DOMPurify library doesn't follow Semantic Versioning, so we have to release every change as a minor version because we cannot be 100% sure whether new features are added to patch DOMPurify releases or not.

In this particular case, it was not dompurify library itself, it was its peer-dependency jsdom that switched to Node 18, so I should have released isomorphic-dompurify as a major version. Node 16 is not supported anymore, so I assumed that it would be relatively safe change but I will be more careful in the future.

To sum up, I cannot guarantee following SemVer approach because it doesn't depend on me but I have added the engines field to package.json to help preventing the situation which you experienced in the future.