Hacker News Reader

Comment by recursivedoubts | Hacker News Reader

this has to be a major mistake on the part of the library developers

it is completely unacceptable to change semantics like this in a post 1.0 minor version

Breaking changes are things, no project is ever done -- ye olde django is still doing big moves like adding async colors, and that's great!

But... CHANGELOG.md with BREAKING CHANGE sections and a major version bump, maybe a DEPRECATED lint and runtime warn() ahead of time, and bam, no surprises for professional teams. For more than that, service contracts are things :)

I don't think you can ever make a breaking change like the one described. There's just no way to audit the correctness of all your users after that change. You need to leave the old thing with the old behavior and only add the new behavior to a new thing.

Rails changed the meaning of NOT and nobody batted an eye - https://til.hashrocket.com/posts/3zyftipjiu-rails-will-chang...

These sorts of changes do in fact happen fairly frequently and developers need to be aware that they can't blindly accept upstream dependency changes.

That also is a really awful change and probably broke someone in production. Really there is no reason for the not function to take more than one argument. But if you have decided to overload the meaning to NAND, you'd better not later change it to NOR!

That is asinine. Why not change it in 5.x->6.0 if they knew it was a problem. Why even use version numbers at that point? Just use DateVer or 0ver at that point.

> Why not change it in 5.x->6.0 if they knew it was a problem

Because Rails explicitly has a versioning policy where minor versions are equivalent to SemVer major versions (but with deprecation notice in a previous minor version) and where major versions are also SemVer major with subjective significance distinctions; they call it “shifted SemVer”.

https://guides.rubyonrails.org/maintenance_policy.html

This is somewhat obnoxious, but not as bad as saying you use real SemVer and then brazenly breaking things in minor releases.

Sure, but like, you don't have to break code on .Y changes.

Changing semantics of a query operator is something worth saving for a "big major" update, if you change it all.

Some breaking changes are really obvious and easy to catch. Others can introduce pernicious bugs which slip through tests. The change Mongoid is solidly the latter. And yeah, they say they use actual Semver.

> Changing semantics of a query operator is something worth saving for a "big major" update, if you change it

Arguably, it was so important that they did a big major update just to deprecate it.

It's the users who need to audit, the social contract of OSS is just not to be sneaky/sloppy about it (when posing as a serious project).

Semvar is beautiful bc it lets you be explicit. Likewise, end users can judge "wow major version 27 in as many months, maybe not so good for us." We had a gov customer today upfront about needing slow updates, and same deal -- maybe our SaaS and OSS libs are too fast moving, so they are probably better off with our enterprise distros.

I am a toil/backwards incompatibility hawk. I don't like to impose them on my customers. It's extremely rare that the balance of equities favors making a change like this, where a function that filters data and will necessarily impact correctness is changed, and not in subtle edge cases but in its primary behavior. In fact, I've never seen a case in my career where it ended up being worth it.

I'm a big fan of Linus' mantra: we don't break userspace.

I agree - we probably err too long on avoiding breaking legacy code: we are about to do our first deprecation in years as the old protocols are getting too unconscionably insecure + costly to maintain relative to our new ones.

But that's company code we get paid to be stable on. Very diff story for OSS we at most contribute to, we don't assume that's part of the social contract.

Linux is also OSS. I don't think this is an OSS/paid dichotomy. This is a good software/bad software dichotomy. Also isn't this library maintained by mongo db anyway? So the "we are doing this for free" excuse does not apply.

Agreed in part, I'd indeed want careful motivation and change management of such a change from my language or DB vendor -- JS/Python takes years for tinier semantic changes :)

The average OSS project is just ~1 fulltime maintainer, maybe 2, with tiny drive-by contributors: there are great studies measuring this. Even most popular and long-lived OSS projects are more like that than Linux. The exceptions are inspiring, but most (my bet, I don't recall stats here) seem to be open core largely driven by 1 company. Something foundational with many contributors under open governance like Linux is better to discuss as an abnormality ("why can't the typical project grow to this size, maturity, tooling, and stability?").

So when talking about modern OSS, the typical case of looking through a pip or npm tree is NOT big shops and instead something closer to a network of volunteer passion project. From such individuals, I'm thankful for semvar, CHANGELOG, CI, and a few niceties like that. From there, the history of BREAKING would signal the project moves too fast for us or with too big swings, or looks more acceptable.

Where I work, the biggest enterprise system we have (ERP) has has a support cycle of ToS upgrades quarterly, with only urgent security patches in-between. And detailed advisories ahead of time on which (depending on modules and features in use) must be updated, may be updated, or can be ignored.

It makes maintenance a highly predictable endeavor:

Update T+0 == dev instance

Update T+1 week == test instance

Update T+2 weeks == prod deployment.

UAT inserted as needed when there are user-facing changes.

Sure. That's what a major version is for.

Reply on news.ycombinator.com