Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It doesn't scale. If you have a->b->c and b version-bumps every time c does, then this also means a has to version-bump. So basically changing one file means everything that depends on it, even indirectly, has to change.

Furthermore, if you have diamond dependencies, a might end up version-bumping more than once.

Regular edits would get lost in a sea of version-bumps.



If C changes and B doesn't reflect the change in its own behavior, then there's no need for a new release of B. Just update it and group it in with the next normal release.

If C changes and B's behavior does reflect it, then A does need to know about it.

The "sea" is limited to times that direct dependencies change their behavior, which is what it already is.


You're assuming that B does regular releases. But if B is "done" it might not happen for quite a while.

Suppose C has a security patch, and B doesn't have any new functionality to release? Does it keep using the version without the security patch forever, because that's what's listed in the import statement? Or does someone have to update it?


I include “security patch” in “behavior”, subject to both conditions above.

If B isn’t otherwise updated at a similar time, then yes, I advocate dependency update-only releases. I think this is as it should be. A project should be able to know what code it runs, specifically.

And yes, if a project is abandoned then security patches don’t get magically applied. Again, as it should be. The fact that you have an unmaintained dependency is itself a problem. You can’t just auto-apply security patches and expect things to keep working, ask any Linux distro. What needs to happen is a fork (or dropping the dependency). Tools warning you encourages this; silently auto-applying patches encourages everybody to separately do their own fixes and workarounds.


I don't think it's reasonable to require each library owner to do regular updates, whether or not they have any changes to make themselves. This is unnecessary busywork. Library maintainers should only be responsible for fixing their own bugs, not responding to everyone else's bugs.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: