If all the world were a monorepo

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.

For me the comparison to monorepo made a lot sense. One of the main features of monorepo is maintaining a DAG of dependencies and use that to decide which tests to run given a code change. CRAN package publishing seems to follow same idea.

That's something you can do just as well with multiple repos though

What a monorepo gives you on top of that is that you can change the dependents in the same PR

> There is no one best way

I think that the laws of physics dictate that there is. If your developers are spawning the galaxy, the speed of development is slower with continuous development than with pinning deps.

for me too - in a way a "virtual" monorepo - as if all these packages belong in some ideal monorepo, even though they don't.

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.

We don't know the laws of physics though. We just have models which can both fit into human brain to a point that they are surprisingly good for what humans have an opportunity to experiment agaisnt. That is really awesome, but it doesn't mean we know.

They’re not confused. It’s an analogy.

Stability vs security, that is what pinning gives you and is why rolling releases are more popular these days. No?

I don't see that. What I do see is an interesting thought experiment in the title and then zero delivery in the body text.

The term clickbait comes to mind.