dependency management problems are a thing irrespective of the license of those dependencies. nobody anywhere is writing assembly code entirely on their own, even then you depend on a compiler. every software project has dependencies. it's a problem solved by version pinning. i can't believe a tech writer wrote this?

@Gargron version pinning means you are potentially missing important bug fixes during codebase refactoring which were actually vulnerability fixes that didn’t get CVEs assigned

@feld no. you gotta be paying attention to new releases of your dependencies (there are tools for this), but version pinning means you don't get unexpected breaking changes from someone else's code.

@Gargron I’ve only witnessed it used to freeze that code for eternity because keeping your codebase compatible with the latest releases of your dependencies is “too much work”
@feld @gargron So, you have the choice of auto-updating and violently breaking your thing even when there's no problem, or pinning and silently staying broken when there's a security update. :-)

@clacke @feld @Gargron ok first of all because I am a jerk,

second of all is that really worse than *not* using open source? I mean, if you're not tracking security holes that other people find, I can't imagine you're actively looking for security holes in code only you can see

@ajordan @gargron @feld Yeah, semver intends to tell you what contracts you have with your dependencies.

But even elm, which enforces that API signatures don't change without bumping versions, cannot enforce that semantics don't change underneath the API signatures.

Short of perfect formal verification, there is no technological solution, because this is a human problem.

@clacke @feld @Gargron oh absolutely, semver is not without its flaws. IMO it's better than anything before it but it doesn't replace e.g. testing. This is why lockfiles exist.

@ajordan @gargron @feld Thank you, and I agree.

I think semver is a good idea and I like it. But even with semver we need lockfiles. But then with lockfiles we need to not fire-and-forget but keep up to date on things.

Belts and braces, people. Goes along with the gum and paper clips we built this stuff on.
@ajordan @feld @gargron

One thing that I want to see more of in the future is what e.g. #rust is doing:

Find the things that depend on your thing -- in their case every single crate published -- and treat them all as integration tests for your API.

#nix and #guix make this easier. I just discovered the brilliant #nox tool, where you can do `nox-review wip` on e.g. a bumped dependency and build and test every dependee.

Imagine if every project did this before releasing their point release! (and at the same time imagine that the dependees have decent tests, of course, otherwise you're just detecting whether you broke API signatures, and that's trivial to do without looking at any code except your own)

@clacke @feld @Gargron fun fact, Node.js actually has some tooling to do this! Though from your description it sounds like it's nowhere near as comprehensive as Rust's.

AJ Jordan

@clacke lmaoooo I have no idea

Maybe a semver-major change landed in git master and it's expected...? Dunno ¯\_(ツ)_/¯

Sign in to participate in the conversation

For people involved in the activities of the World Wide Web Consortium (W3C), in Working Groups or Community Groups, and people who follow the work of the W3C. Run on a volunteer basis by Sandro Hawke and others, NOT the W3C systems team, and NOT supported by W3C. Uses the W3C Code of Ethics and Professional Conduct. A place to talk online about the things you would talk about in a meeting, or at a meal with your group. We plan to have a relay-bot soon, so don't feel like you need an account here to be a member of this online community. Please post things you think the W3C community might find interesting!