I agree with this 100%. I recently tried to update an old iOS app written in Swift. I would have to install an older version of Xcode to upgrade Swift from vers

I agree with this 100%. I recently tried to update an old iOS app written in Swift. I would have to install an older version of Xcode to upgrade Swift from version 2 to 3, and then use the latest Xcode upgrade from 3 to 4. Then I'd have to update every single dependency and figure out any breaking changes. I wanted to see if I could hire someone to help me with this, but they just gave up after looking at it, and recommended rewriting the whole project from scratch. (It's a hobby project so I don't have the budget for a rewrite.) This is generally how dependencies work across all languages and frameworks, and I think the status quo is extremely inefficient. When a library maintainer releases updates with breaking changes, we waste thousands of developer-hours on upgrades and fixing all these changes. I've been thinking about a new kind of package manager and repository that strictly enforces a certain level of test coverage, and also forces library maintainers to codify the upgrade process. For example, if you decide that you want to rename a `get` method in `v0.1.0` to `fetch` in `v1.0.0`, then your `v1.0.0` release MUST include an automated code-mod script that automatically runs when a developer updates the library version. This wouldn't work so well for dynamically typed languages, but this rename example should work flawlessly in a statically-typed language. The code-mod script should also include lots of test cases, and be tested on lots of other real-world libraries. Similar to how Rust developers detect regressions in the Rust compiler by building a large number of crates. There's probably a lot of reasons why this wouldn't work in the real world, but one can dream! There was a lot of controversies when Elm made this kind of decision about their package ecosystem and removed native modules [2]. Deno is working on a high quality Standard Library [4] with no external dependencies, and where all code is reviewed by the Deno core team (and presumably with a high level of test coverage.) [1] https://github.com/rust-lang/crater https://github.com/rust-lang/crater [2] https://dev.to/kspeakman/elm-019-broke-us--khn https://dev.to/kspeakman/elm-019-broke-us--khn [3] https://news.ycombinator.com/item?id=17842400 https://news.ycombinator.com/item?id=17842400 [4] https://deno.land/std https://deno.land/std