Hacker News Reader

I can only imagine the amount of new version conflicts that this would generate (I've already seen more than I'd like) if we would no longer go "1.8.0 has a feature that we depend on, so 1.8.0 and newer". Every time every dependency gets an update, every dependent package would need updating too (or at least its metadata). Hell no.

Perhaps go for a range + last tested version, e.g. "1.9.7 worked" so when 2.0 comes out and breaks, you know what to use instead.

View on HN

That’s how semver ranges work, in fact saying `^1.3.12` means “I tested for v1.3.12 and I want all non-breaking updates that come afterwards”.

Well, if you already know which updates are non-breaking, of course you have solved this problem.

Indeed.

If you change the output of "ls", you know everything that uses ls will break and you can bump a major version. But if you change e.g. the date format to include a timezone (visible when -l is specified), does such a change really warrant a major version bump? It's just a minor change but it might still break things. Or maybe if you refactor some stuff in curl, the curl-dev package might suddenly be incompatible with something that depended on it.

Reply on news.ycombinator.com