I saw an issue today on a fairly popular project (better-auth, see the link to the issue attached). No repro, no context, just a wall of caps and profanity ending in “fuck you”. The maintainers ship this for free. People run production businesses on top of it, for free. And the thanks is someone raging into a text box because a minor bump cost them an afternoon.
I maintain and contribute to a few projects myself, so this hits a nerve a bit. Something people don’t see from the outside: it’s not enough to know how to build the thing. You also have to know how to defuse a thread where someone’s insulting you and not fire back, even though most of us aren’t paid for any of it, let alone the work of staying civil while being told to get fucked.
I’m not pretending breaking changes don’t cause real pain (that’s what the issue is about). But I keep coming back to a boundary question: if you’re not paying for it, do you actually get to demand anything? (Obviously yes, but we still need some boundaries)
I believe healthy open source needs more Optimocracy
I mean, I told a paying customer to get fucked yesterday over demands so you can definitely say it to a non-paying person.
If he was a paying customer of mine i would void the purchase and tell him to go fuck himself
Let me preface this by saying that you should never, ever be rude to open source maintainers.
But good god, if you are writing software for other programmers, stop making breaking changes. By all means, break your software. Don’t break mine.
If there’s something I learned in the industry is how to test (and I don’t just mean some unit tests) and how to write APIs with back compatibility in mind.
Not saying proprietary software is necessarily better, but working in a big organization that guarantees functionality to its customers, does teach you to coordinate releases better than most solo projects probably will.
Imagine the chaos if all the FOSS maintainers collectively went on strike until their demands were met. They could demand so, so much despite being volunteers.
I’m convinced the world’s top companies are all secretly built on FOSS projects, so might be able to scrape together a few billions from it.
They would sooner enslave the maintainers
Agree we should treat people better but also: for the love of god learn semver. Breaking changes in minor and patches is so sloppy.
But still complainers fault for not pinning, because you cannot trust semver at all. Vicious cycle
All companies I worked for did not care for semver and made the fucking marketing department decide on the version numbers. Makes you never trust it.
“NOO!! The free thing you’re providing for free that my business is mooching off of changed and I don’t want to learn how to use package managers 😡”
Some people deserve nothing for free, they don’t get the simple idea of what free job for community means, if you are worried about bugs and etc go get payed work. So you have a reason to demmand shit
Why not fire back? It’s not like you can really get fired from an open source project.
Hasn’t hurt Linus either.
The part that irkes me most about this, is he’s right.
The complaint is valid, non-breaking production changes should be the norm, not the expected, 100%. And yes, I maintain upstream work, too.
Doesn’t forgive them being a dick. Permaban in my book, I just hate that he’s right.
Are they right though? Not every project follows semver, it’s on consumers to pay attention. Especially if it’s a recurring problem: this problem (assuming the project follows semver) hould happen once at most.
Right or wrong in versioning is always a debate, but for me, breaking changes on non-major versions is not. I run a number of projects, and it’s the one thing I avoid at all costs.
The last thing a container user wants is a difficult update, it’s the reason we end up with outdated vulnerable software floating around. And it only takes getting bitten by it once to always be weary of a future update.
I’m not pretending breaking changes don’t cause real pain (that’s what the issue is about). But I keep coming back to a boundary question: if you’re not paying for it, do you actually get to demand anything? (Obviously yes, but we still need some boundaries)
And if the issue makes you lose face, it’s clear you’ve been dealing with it for quite some time and should’ve learned to lock your dependencies and test after updates. Unacceptable.
Open source development/maintenance is not a thankless job, it is a job that society has not committed to normalizing materially supporting. Those might feel the same, but they are not and it is childish to pretend they are.
“Sorry about that. We will issue a full refund.”
Guarantee triple their money back
Naah, I don’t really demand anything if the author breaks something on update. I just asked if the breaking changes are intentional and if there’s a workaround. Failing that, I revert and look for other libraries or roll my own. To me Open Source is always about making something you love without any obligation. Not even to follow semver.
That view of open source only applies for non-profits and hobbyists, releasing code that solves their problems altruistically.
Corporations, startups, and VC’s abuse open source by using it as a means to gain goodwill and trust until they are funded or profitable, then they perform a bait and switch or other parasitic practices; they deserve the hate, and can eat shit and die.
Also, if you’re not gonna follow semver don’t use semver. Just use YYYY-MM-DD or whatever. Quite simple really.
Regarding this project; anyone who chooses to use new (thus untrustworthy) foss libraries in prod without version pinning and thorough integration testing is an idiot.
V1.2.3 is not unique to semver tho. So it could really be anything like linux 7.1.2. To be fair, linux does predate semver by a long time. But the point is that not every software with #.#.# needs to be semver. And I think better-auth, from the issue linked, has stated that they don’t yet follow semver somewhere in their docs.
If the versioning has no meaning, or conflicts with a widely held standard, why not switch to datever? Then we at least know how out of date we are…
I ask the inverse. Why should you demand that every project that uses x.y.z versioning be a semver? A widely held standard only applies if you actually want to follow it in the first place. You know HTTP spec didn’t mention anything about the body in GET requests and so almost every web server just ignores body on GET? Yeah, some software decided to use that. And guess what? That software? It was Elasticsearch. People are free to do whatever they want with their software. If they decided to publish something non standard and you decided to use it, you can ask them nicely to follow standard, or make an adapter for it.
Yeah, choosing to establish the semver social contract and then break it is not great
But they never established a “semver social contract”. You can’t assume that project follows semver just because it has an x.y.z version number; semver is not the only versioning scheme, it’s just a very popular one
Hmm, fair
Why would you use the syntax of the most widely adopted versioning schema in software engineering, then not follow it?
This isn’t linux; it’s a 2 year old project ffs. That’s just ignorance or incompetence, but poor design decisions are expected from an AI slop project. Unless you can enlighten us on the logic of the chosen schema, you shouldn’t defend them.
This is the first time I’m hearing about semver contract. I always assumed the x.y.z versioning was pridever, which was the first definition I found. And that says nothing about backwards compatibility.
So it might as well be the case of the XKCD.
If you do not know about semver then you are not a programmer. It’s in the first paragraph https://en.wikipedia.org/wiki/Software_versioning
I don’t think there’s a particular need to defuse into a productive discussion. Something like that, with no repro or respect - lock and close, with a comment on why/that onproductive and disrespectful/what it could have been.
Tone should always be respectful. Something like this should have been a respectful, open suggestion, explaining the issues no clear semver causes.
If they don’t respond to your needs - you can accept it or leave/fork.
Complains about improper release management.
Apparently not using lockfiles for prod.
This is not a serious developer.
What makes you think it’s a lockfile issue? If they sighted a patch upgrade then updated the lockfiles but then noticed a breaking change, then lockfiles are irrelevant.
If it’s actually like they claim, I understand the frustration. (Not that I know this project in particular or how it gets integrated.) Without clear versioning and/or changelogs/release notes managing upgrades is cumbersome, sometimes impossible.
In some cases I’ve had to ask for clarification in PRs because release notes were not clear, PR was not clear, and resolved ticket was also not clear on the thing or solution.
Apparently they had issues before, so maybe they could have expected “patch may not be patch-only”.
It’s the combination of “breaking changes on minor releases” and “disregard for … production environments”.
Can you stop releasing breaking changes on minor releases? It’s absolutely infuriating that you guys keep doing this over and over again with complete disregard for people downstream using this package in production environments.
By the time you’re deploying to production, you should already have your versions locked in, so semver does not factor into resolving dependencies for production deployments at all.
I can understand it being annoying for development processes. Like, if you have a dependabot-style tool that tests against new releases and submits PRs for them, that can definitely be a waste of time and attention if it fails frequently on patch-level updates.
But in between that “eager testing” step and a production rollout, there needs to be a moment where a human reviews the updates and signs off on updating the lockfile.
And at that moment, reading the changelog, it really doesn’t matter if it says “1.0.1: breaking changes!” or “2.0.0: breaking changes!”, because you need to be looking at the substance of the update.
The only way semver violations burn you in a prod env is if you’re YOLOing new versions out there, either by forgoing a lockfile or by merging lockfile updates without review.
The reasonableness of your assertion kind of comes down to environment. Say NPM where people go nuts with dependencies (and is the subject here). If for instance there is a security issue in a package used by the package in question and you must update the package in question to get the package with the security warning updated, then you must update the package in question, and there is every expectation in the NPM ecosystem that semver is followed.
That said, being rude to the developers is immature and counterproductive, and moving to a different solution if a package repeatedly causes problems would be the sane course of action.
