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.
Very fair point :) All my other dependencies, using 5 year old versions is fine; it’s mostly just PHP that gets an order of magnitude less-painful to work with in each release, so being stuck a few versions behind is extra frustrating...
Though I concur that your caveats are valid, I do think dependencies should be upgraded to newest-LTS sooner rather than later. Once the dependency falls out of upstream maintenance, it's a time bomb; and we've found (inhouse stuff for public website consumption) that if you don't do the upgrade to newest-LTS sooner, you never quite get around to it until it blows up in your face. And that's not so good.
We keep finding over and over that the wonderfully-engineered project is thrown away after about three years, but that nothing lingers longer than a temporary hack. So we're getting better at futureproofing our temporary hacks ...
Being able to create consistent builds seems more important to me than being forced to fix builds because random packages changed their API.
You're right that it is technical debt to not be on the latest version, but if I need to roll back to a previous (of my application) version due to a regression, I want to be 100% sure I get the exact same state as I did before. If my dependency management software doesn't solve this, it's not good enough.
My opinions on this have changed a lot over the past few years. At this point, I think anything that pins dependencies to specific versions is asking for long-term maintainability nightmares. Updates of your dependencies, operating system, language version, etc. should happen weekly, and any instance where you have to pin a dependency to an old version (e.g., a major version release that has some compatibility issues) should be dealt with ASAP.
Obviously this isn't a tenable position in every circumstance, but I think it should be the default. Particularly in a world where the vast majority of security fixes go without an announcement or CVE.
Agree in principle, but I'm giving advice to someone who programs on occasion and is primarily concerned with their programs breaking due to dependency version upgrades when they come back to them after a little while.
I think the last option you mentioned is (effectively) the best of both worlds. Lock down dependencies explicitly for the sake of reproducibility, but make it very easy to upgrade (as automatically as possible).
That doesn't work unless you can assume that every developer is willing to install all the dependencies of your project globally, with no control over what versions are used.
The default should be to update constantly. Expecting developers to remember to manually trigger updates just results in perpetually-stale dependencies. If a specific issue is found with a newer version, then having the ability to explicitly pin to an old version is reasonable.
> When you have a project with a 1000+ dependencies, all pulled latest, nothing will ever compile, let alone your own code.
The problem is having a project with 1,000+ dependencies that are apparently such low quality that their authors issue build-breaking changes daily.
I think package managers should have an option to run a build of your package using the oldest versions instead of newest versions, just to validate that the build works, but that this shouldn't be the normal way to resolve dependencies.
I think the problem you're assuming here is that dependencies are automatically updated to use the latest version. That sounds like pretty strong coupling in a way that means other problems are lurking somewhere.
Team A should be able to develop without having to consult Team B constantly. That means you have to be mature about deprecating things before you just remove them, but I think that's what the whole article is about.
Updating to the latest version and running it shouldn't be how you review them for dependencies. You can follow the development of a few packages you care about and review them immediately, while not blindly running cutting-edge everything at all times.
We can only hope they'll at least have a tool that you can run that will bump up all the versions to specify the latest. But then of course that will make solving dependencies a lot harder since it's much more likely you'll get an unsolvable set of deps. It's hard to see how this could ever help anything.
Lock files also have the major advantage that you have a hash of the thing you're downloading so you're not depending on the maintainer not e.g. force pushing something.
Why do you want to update your dependencies if they work? Isn't the whole point of dependency management to avoid using different versions of dependencies than the ones they have been tested on?
If you don't refactor and update your dependencies regularly you can easily end-up in a corner.
You can be hit by a bug in your dependencies, be it a functional one or a security one, but if your dependencies are completely out of date and there is tons of API incompatibilities between the version you are using, and the version implementing the bug fix, it will be really painful and take a long time to update, with stakeholders breathing down your neck expecting a fix asap.
Also, maintaining old tool chains can be a real drag (maintaining older building hosts, developer machines or VMs).
Updating frequently to be near enough the latest version is generally preferable.
Without those pesky new features and breaking changes that come with using bleeding-edge releases.
This is usually a popular counterargument when people are talking about keeping everything up to date. What people should consider though is to try to keep everything *relatively* up to date, without always being on the latest version but still not very far away from the latest release.
GitHub, Stack Overflow, etc., are full of data about potential issues when updating to library X to version Y, and usually, you're able to find this when it's too late - either you've got an error in production or you're in the middle of an update and you discover that there are some issues with the version that you want to use.
Exploring these data points is still a pretty much untapped area, and this is something that I'm trying to explore with my product that updates dependencies automatically in a more "smarter" and autonomous way at depshub.com.
I would be happy to see more people working in this area since it's clear that there is a problem that needs to be solved and unfortunately the current status quo is "while everyone needs to manage dependencies, there's no one right way to do it, so everyone does it their own way."
reply