Js-beautify: Review version numbering policies

[bitwiseman]

This project is extremely popular and as such needs to be stable, solid, and more conservative in versioning and changes.

We've been using semantic versioning reasonably accurately. There have been no breaks to backward compatibility in sometime, and the most changes are bug fixes.

However, semver only encodes intentional breaking changes, it doesn't address potentially risky changes. We should consider a change's risk of causing breakage in our version numbers.

Also, many projects do not not lock or even limit their version dependencies. Those that do often use ^x.y.z instead of ~x.y.z, which would mean they take updates when y or z change.

Consider switching to making major version updates under more circumstances to limit risk to dependent projects.

[laggingreflex]

These tools might be relevant:

https://github.com/bahmutov/dont-break
https://github.com/semantic-release/semantic-release
https://github.com/conventional-changelog/standard-version

[bitwiseman]

From #1784:
The project does follow semantic versioning to the extent that is reasonable in this area.

We use major version to indicate API compatibility. This project has never made API incompatible changes. There are a number of options that have been retained for backward compatibility.

The question then is what is the definition of "backward compatible" when it comes to formatting output? If we say any change to output is not backward compatible" then every change will be a new major version. That would actually less informative for the consumers of this library - they would not know whether a release is API compatible or not.

We use minor versions to indicate significant formatting fixes or added features.
We use patch versions to indicate small bug fixes formatting fixes or added options that cannot cause any side effects.

We do not make spurious changes the output, but output for a given input MAY change for minor or patch versions. For changes that fix formatting errors (making the output more accurate), we turn those on by default and may or may not provide the ability to turn them off. We only do this only when the formatting was strictly incorrect. All other changes should be added as formatting options, which must be off by default such that the default formatting of valid input doesn't change whenever a feature is added.

Best effort is made to handle invalid inputs in a reasonable way as well, but that is not a priority.