Because nobody got around to fixing it yet. Infrastructure can be built to keep these packages' dependencies up-to-date by default. If they break on dependency update, the maintainer should be alerted, and the package should no longer be recommended until it is fixed. Relying on individual maintainers to do everything correctly themselves has never worked.
Traditionally package maintainers has kept dependencies up to date. This has changed with vendored dependencies where upstreams have to do the work. They are not always up for that work. This isn't strange, nor weird and the comparison to chrome and google doesn't make much sense.
Looking at the dependency listing I'm trying to figure out why this would be. There are like 4 dependencies here in the largest of these containers, so why is it so difficult to keep them up to date?
This is because packages relie on each other to work. They don't just bundle all their dependencies. So maintainers have to update package based on the dependancies version that are in the repositories.
Every package updating alone (or updating all its dependancies) might make everything break on the system.
So there is a compromise here to get smaller packages, that don't bundle everything but reuse other packages.
If you want packages that bundle everything, then you can use snap / flatpack, they are exactly designed for this.
In practice the apps that don’t publish updated dependency lists are also the ones that end up breaking by when you do update their dependencies. It only works in the simplest of patch versions.
Since simply updating the dependency can easily break the resulting package, this need to re-test is not something that can be avoided by making some other choice of packaging e.g. the current one - it's not adding a new burden, it's acknowledging that it already exists (indeed, IMHO much of what the original article complains about). If there are no resources to carry that burden, then the only option seems to be to wait for an updated release from the upstream, whenever that arrives.
Maintainers aren't going to keep outdated packages around forever, even if you "work with them". In effect, there is some ongoing maintenance there either way. If I just maintain my own dependencies, then I don't have to work with maintainers from a dozen distributions.
One reason is that many developers work with package managers / languages that are INCAPABLE of handling multiple versions of the same dependency. Without this you quickly get version deadlocks without semver.
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.
Dependencies should be nailed to versions and upgraded conservatively. The default shouldn't be the latest and greatest, it should be the last thing that worked.
The problem is that in the real world despite promises of semantic versioning, breaking often occurs which makes it impossible for two packages to depend on the same version of another library though in theory they should.
Because dependencies are not perfectly managed / versioned. When you release the end product app, you have 3 options:
- assume that your published version compatibility is correct and let the app fail for some library upgrade in the future
- publish a strict list of dependency versions and keep updating it
- publish a strict list of dependency versions and rely on old versions as long as possible
The first one results in unhappy users, second one in lack of distro packages because you rely on too recent deps, third one either in lack of distro packages because of too old deps or in unhappy users because deps don't work on their new system anymore. There's no way to satisfy everyone unless distributions themselves become aware of multiple levels of package management.
Well, why did you choose packages that change quickly and are poorly documented then? There are packages that, OTOH, have up to zero dependencies, and haven't changed in years; if you consider those stale, I guess nobody can help you.
I've been 'forced to upgrade' in the past by issues in dependencies that won't be fixed, with other dependencies not updated yet. It's a sticky wicket.
That said, breaking changes every six months seems to be commonplace in major open source packages. My initial reaction was 'OMG, now they want to repeat the Angular 2 debacle every 6 months?!?', which doesn't seem to be the case.
The only times I've ever run into issues updating dependencies (other than across major version upgrades of deeply-integrated deps) is when people have put it off for months or more.
Most updates aren't breaking. The overwhelming majority of updates that are breaking are trivially discovered and fixed with one or two tweaks. Almost all the rest can be fixed with a single search/replace.
Being eight minor versions (or two major versions) behind and having to find and fix all of these at once is when people land themselves into trouble.
reply