Hacker News Reader

Comment by cardanome | Hacker News Reader

I agree with the message but wish they had picked another example.

If you remove a feature within just a few months of warning, users will be pissed. I think it is valid to feel frustrated about that. Its unrealistic to closely follow the development of every package you are using.

Now, I am NOT saying they are entitled to a solution. I am just saying, if you declare something stable (if you don't, do whatever you want) then you are creating a certain expectation and you should be very cautious not not break the expectation.

My intention is simply for the sake of the discussion to separate the two issues: There is the entitlement issue. There is also the issue of certain libraries and frameworks that keep changing things.

View on HN

> Its unrealistic to closely follow the development of every package you are using.

You've just abdicated all responsibility here! It is realistic -- not to mention being the core part of our job -- to closely follow the development of ALL code in your application. No matter whether you wrote it, your coworker wrote it, or it was written by a volunteer halfway around the world, if it's running YOUR application, it's YOUR code. You've just chosen to outsource the maintenance of said code to someone you've never met and have no intention of paying.

If you wouldn't pick some random asshole off the street to sit down at your desk and mess around in your production environment without at least peeking over their shoulder, why would you take some random stranger's code and shove it in your codebase without vetting it?

So yes, it IS possible and IT IS YOUR JOB to follow the development of all the code that runs your system. That random asshole off the street offering you code for free owes you nothing more.

> Its unrealistic to closely follow the development of every package you are using.

It's very realistic and viable for huge corps with infinite pockets for dev budgets.

I worked only a handful of times for huge corps. The better ones had extremely hygienic and structured approach to relying on open-source, namely they were inspecting CHANGELOGs and were testing carefully before each version bump.

And they were quite right to do so. It should go without saying that when you get stuff for free you get zero guarantees. You gotta guarantee things yourself. Today it works, tomorrow a new version comes out that might break your software. Update at your own discretion and pace.

RE: your last line, if you truly need a piece of software but its maintainers change things too often then, well, it's time to roll up your sleeves and write your own. Again, huge corps can afford that.

It looks like the change is from an upstream software. Homebrew did communicate the change, which is something that I wouldn't expect from a distributor. In Debian, we have the NEWS file to communicate such breaking changes, but it is seldomly used because most users don't want to be spammed with changes they are not concerned with. Bothering the distributor for changes in upstream software was OK ten years ago. Today, it is not: too many upstreams, not enough people to curate and maintain.

> There is also the issue of certain libraries and frameworks that keep changing things.

Then it's up to the people burned by this to use a different one. If you want a stable interface/API, make sure that's part of your decision-making process when you choose the tools you build atop.

The proliferation of easy-update-path tooling across platforms has hidden that fact that managing dependencies is a critical part of providing software and software-based services.

That's the life of the package maintainer. You get grief from users that complain about upstream issues, and upstream that doesn't like you reporting issues to them.

I agree and i think that important task of projects is to manage user expectations by clearly stating what they offer. Some projects offer stability guarantees, some projects just keep changing things. If these approaches are well-communicated, then users would be less frustrated when their expectations are not met. But truth is, i personally would not use the second class of projects unless i am desperate.

Reply on news.ycombinator.com