4 ms·

Both extremes are bad. If you never change anything, you are left behind on a lot of security updates and bug fixes. The longer you wait the harder it is to mo

Both extremes are bad. If you never change anything, you are left behind on a lot of security updates and bug fixes. The longer you wait the harder it is to move. The “stay current” model comes with risks too. It’s just a matter of figuring out which manner has the better value to risk trade off, and how to mitigate the risks.

goodpoint 5y ago
> It’s just a matter of figuring out which manner has the better value to risk trade off This is also bad. If you want to have both stability/reliability and also receive security updates you need somebody to track security issues and selectively backport patches. This is what some Linux distribution do. Mainly Debian, Ubuntu, paid versions of SuSE and Red Had and so on
snapetom 5y ago
The solution was, and always been, to have someone review every commit to the libraries that your app uses, and raise red flags for security vulnerabilities and breaking changes to your application. Oh, boy, I would love to work for a company that has someone like that. Know of any? At the least, I would love for a company to just give me time to review library changes with any sort of detail.
actually_a_dog 5y ago
One company I worked for had a bot that would periodically go and try to upgrade each individual app dependency, then see if everything built and passed tests. If it got a green build, it would make a PR with the upgrades, which you could then either choose to merge, or tell the bot to STFU about that dependency (or optionally, STFU until $SOME_NEWER_VERSION or higher is available, or there's a security issue with the current version). If not, it would send a complain-y email to the dev team about it, which we could either silence or address by manually doing the upgrade. This worked out rather well for us. I think the net effect of having the bot was to make sure we devs actually paid attention to what versions of our dependencies we were using.
ASalazarMX 5y ago
The sweet spot would be using a lock file for reproducible builds, and programmed dependency upgrades. Before the dependency upgrade you can check if the new version breaks something and plan for it. I've used this in Python, where I try to keep dependencies to a minimum. I don't know if that would work in JavaScript, the dependency tree is huge there.

goodpoint 5y ago

> It’s just a matter of figuring out which manner has the better value to risk trade off This is also bad. If you want to have both stability/reliability and also receive security updates you need somebody to track security issues and selectively backport patches. This is what some Linux distribution do. Mainly Debian, Ubuntu, paid versions of SuSE and Red Had and so on

snapetom 5y ago

The solution was, and always been, to have someone review every commit to the libraries that your app uses, and raise red flags for security vulnerabilities and breaking changes to your application. Oh, boy, I would love to work for a company that has someone like that. Know of any? At the least, I would love for a company to just give me time to review library changes with any sort of detail.

actually_a_dog 5y ago

One company I worked for had a bot that would periodically go and try to upgrade each individual app dependency, then see if everything built and passed tests. If it got a green build, it would make a PR with the upgrades, which you could then either choose to merge, or tell the bot to STFU about that dependency (or optionally, STFU until $SOME_NEWER_VERSION or higher is available, or there's a security issue with the current version). If not, it would send a complain-y email to the dev team about it, which we could either silence or address by manually doing the upgrade. This worked out rather well for us. I think the net effect of having the bot was to make sure we devs actually paid attention to what versions of our dependencies we were using.

ASalazarMX 5y ago

The sweet spot would be using a lock file for reproducible builds, and programmed dependency upgrades. Before the dependency upgrade you can check if the new version breaks something and plan for it. I've used this in Python, where I try to keep dependencies to a minimum. I don't know if that would work in JavaScript, the dependency tree is huge there.