←back to thread

207 points sebg | 1 comments | | HN request time: 0.386s | source
Show context
0xbadcafebee ◴[] No.45310332[source]
The author is a little confused. A system that blocks releases on defects and doesn't pin versions is continuous integration, not a monorepo. The two are not synonymous. Monorepos often use continuous integration to ensure their integrity, but you can use continuous integration without a monorepo, and monorepos can be used without continuous integration.

> But the migration had a steep cost: over 6 years later, there are thousands of projects still stuck on an older version.

This is a feature, not a bug. The pinning of versions allows systems to independently maintain their own dependency trees. This is how your Linux distribution actually remains stable (or used to, before the onslaught of "rolling release" distributions, and the infection of the "automatically updating application" into product development culture, which constantly leaves me with non-functional Mobile applications whereupon I am forced to update them once a week). You set the versions, and nothing changes, so you can keep using the same software, and it doesn't break. Until you choose to upgrade it and deal with all the breaking shit.

Every decision in life is a tradeoff. Do you go with no version numbers at all, always updating, always fixing things? Or do you always require version numbers, keeping things stable, but having difficulty updating because of a lack of compatible versions? Or do you find some middle ground? There are pros and cons to all these decisions. There is no one best way, only different ways.

replies(5): >>45310570 #>>45311125 #>>45311569 #>>45312490 #>>45313236 #
1. freehorse ◴[] No.45311569[source]
The problem with pinning dependencies is clashing transitive dependencies over a bunch of dependencies. For me this happens in python every third time I try to run sth new even though version numbers are pinned (things can still fail in your system, or you may want to include dependencies with incompatible transitive dependencies). I have never happened with R, and now I know why.

The actual trade off is end user experience and ease, vs package developer experience and ease. It is not about updating R or a package; it is when somebody tries to create or run a project not getting into a clash of dependencies for reasons that can hardly be controlled by either them or the package developer.