Package Management: The problem with using version ranges

Too many open source projects fail to ensure non-breaking changes or long term support of multiple release versions.

So either you rely on greatest(>) that has no guarantees to not break and not just patches (~), you try patches and a new release is effectively end of support or you rely on greatest, fail to do a regular audit and realise the dependency is no longer in active development and will receive any updates (which upon typical discovery would require a change of dependency used).

Security isn't just about vulnerability, and I don't like to ask it (because it isn't universal), but is not a risk of system failure often worse than a risk of system vulnerability? It depends somewhat on how critical the system is and defaulting to explicit versions instead of latest is probably a better practice in my opinion.

I've done development using NodeJs and on the JVM and found I had far fewer problems with Java dependency management.

Semver ranges (dependency 1.0.x) along with version pinning (lock files that represent the currently installed versions) are the best-case scenario. One can avoid the exercise of "bumping versions" every once in a while (just upgrade all packages within supported semver ranges), get the same semver compatibility guarantees, makes sure all other team members are using same versions, and most importantly the CI process is reproduceable and can be sped up with reliable, non-broken dependency caching.

The elephant in the room is Java. Despite its maturity, both mvn and gradle have poor support for ranges and pretty much no concept of lock files. Everyone is left to "bumping versions" by hand all the time, and snapshot versions are pretty much hell and lead to irreproduceable builds.

Vendoring the whole tree is only an optional add-on to semver ranges. You can't vendor a whole tree and resolve all nested dependencies if everyone is using directly pinned versions! I think the article might have a fundamental misunderstanding between versioning as a library author and as a user.

TL;DR - Semver ranges are great when coupled with version pinning and lock files. If not, there are some trade-offs, and as long as people are aware of the trade-offs, its still better than no ranges.

If you read the whole article, I conclude with recommending lockfiles and npm shrinkwrap, the traditional JS lockfile solution. Yarn is the new kid and awesome and deserves mention too.

Lockfiles are an appropriate choice for JS because of unique dependency loading. For Java and many other ecosystems, fixed versions are appropriate because they automatically deduplicate.

There are pros and cons. The absolute most important thing is to achieve determinism. Programming is hard enough as it is.

Yes, the developer might like a library, middleware, application server or whatever to be a specific version, but that ignores that in a production environment you can be behind on security fixes.

It's completely reasonable to lock your code a specific major release of some dependency, assuming it's still being patched, but minor release should be something your patch management solution just applies.

From an operational point of view, I think the original approach of Go, where HEAD of a dependency was just pulled from the repository of the dependency, is the right way to go. If something break, you fix it, because it needs to be done a some point anyway.

I see this all the time with Java middleware. Some developer specifies that we need JBoss version X.Y.Z and not patch unless they say so. At the same time we're required to patch the operation system with the latest security patches. Well what's the point of that if the only service exposed to the Internet is the only thing not being patched?

But version pinning is probably the best way at the moment.

This way the maintainers can use ranges and the developers can pin what they really need in the end-product.

There are more developers than maintainers, so this scales much better.

In PHP we usually have a version range in libraries' dependencies and lock file that specifies exact dependency versions for the entire application. So you can be sure that you get tested combinantion of libraries.

How is this possible is beyond my comprehension. Someone, anyone break something and I have no standard way to bypass "dll hell" (putting space problems aside)? what the actual f.

For example, there's a long tail of one-off packages on Hackage that are really valuable to keep around, even if they're not actively maintained and bumping versions would cause breaking changes. I'm thinking of all the various logic frameworks, theorem provers, etc. which are out there; maybe to accompany some paper from the 90s. They're certainly not "core functionality", but every now and then it may turn out that one of them is exactly what is needed in some app/library. Every few years the major repos may drop the last working version of GHC, so someone may have to step up and do the required fixes, but that's few and far between.

These days I use a combination of Hackage (all versions of all packages), Cabal (to solve dependencies), tinc (to make Cabal deterministic) and Nix (to cache everything).

Stackage puts considerable effort on the whole community to ensure that packages remain compatible, and forces package publishers (developers) to update their packages in a timely manner (otherwise the package will be dropped from the snapshot). That works in the Haskell community, but I'd be hard pressed to believe any javascript developer who has a package on npm.org would put the same amount of effort into keeping it up to date.

Because other people have different priorities and have come to a different cost/benefit ratio value than you?

Another reason is that many developers are obsessing on getting the latest version of their dependencies for fear of security issues or just missing out on the latest and greatest - and they often completely ignore retesting the application since they now have someone to blame if it fails (that other developer should not have pushed the breaking change with a minor version bump!)

I agree with you that it should be the standard to have fixed versions and update your dependencies at a time of your choosing so that everything can get tested properly - but it seems to be an uphill battle.