Pg-promise: Breaking Change in Minor Version

[ForbesLindesay]

Release 8.6.0 contained two breaking changes (one of which is marked as such in the release notes) even though it is not a major version.

This briefly took down our application in staging with nothing other than an update to the yarn.lock file. The breaking change that caused our app to fail was the introduction of asssert-options which caused an options object that contained some un-used keys (that were used elsewhere) to begin throwing exceptions.

Although this change was not marked a breaking in the release notes, I notice that there is a change that is marked as a breaking change in the release notes, which should have made it a major version release anyway.

We have pinned to an exact version for now. Please can you follow semver.

[vitaly-t]

We have pinned to an exact version for now

This is the right approach to using public repositories today. And this is not just my perspective, but other packages, here starting with pg, keep doping the same on minor versions. Practice shows it is too dangerous not to fix versions. This is why all my libraries and projects are all version-fixed, which is what I advise you to do also :wink: Many dependent packages also followed the suit, like Massive.js, they now all use fixed versions only.

Please can you follow semver.

This only works in theory. I did follow it for a few years, then gave up. And in case with pg-promise, if I did follow it, it would be over v100.0.0 by now, and I'm not cool with that. I only increment the high version over major breaking changes.

[ForbesLindesay]

This is the second time I've seen a semver break affecting my production code in 7 years of working with node.js on a daily basis. The problem results from a tiny number of package maintainers ignoring semver, which usually comes from the belief that integers are somehow in short supply.

It is possible that by now you might be on version 100, but more likely it would be something like version 20. Even if you were on version 100, which would be fine, it would take at least 40 years to get to version 1000, and well over 400 years to get to version 10000.

The cost of a larger version number for the major version is essentially 0. How many people have chosen not to use jest just because their major version number is now 24? The cost of not being able to tell when a version will be a breaking change is incalculable.

[vitaly-t]

Fair enough, I will keep that in mind for the next breaking changes.

I am also locking this conversation, because pouring your negativity on Twitter to have this support forum bombarded by your Twitter followers is low. Please do not do this again, or I will ban your account here.