5 ms·

Yes, nowadays it is very common for software to pin its version. This practice strikes me as questionable. One danger is that dependencies are not getting updat

by cjfd 6y ago

Yes, nowadays it is very common for software to pin its version. This practice strikes me as questionable. One danger is that dependencies are not getting updated regularly and one day one find oneself depending on a very old version of a dependency. The other is that it may not always be possible/practical for other people to be at the that exact version. Some libraries can depend on system libraries that cannot be easily upgraded. E.g., numpy depends on underlying system libraries and it is not always possible to choose whatever version. GUI-libraries ultimateley depend on system GUI-libraries which also, practically speaking, cannot be updated to any random version. It sure is a pain that occasionally a dependency breaks. One question that one can ask, though, is whether one wants to experience that pain sooner or later. I am thinking of https://martinfowler.com/bliki/FrequencyReducesDifficulty.html https://martinfowler.com/bliki/FrequencyReducesDifficulty.ht... here.

Silhouette 6y ago
One danger is that dependencies are not getting updated regularly and one day one find oneself depending on a very old version of a dependency. That is only a problem if the old dependency no longer provides the required functionality, though. In many cases, that will never happen. The other is that it may not always be possible/practical for other people to be at the that exact version. Some libraries can depend on system libraries that cannot be easily upgraded. E.g., numpy depends on underlying system libraries and it is not always possible to choose whatever version. GUI-libraries ultimateley depend on system GUI-libraries which also, practically speaking, cannot be updated to any random version. Ironically, the problem you've described here originates with dependencies not having stable dependencies themselves. This is why it's so important for foundations like operating system or other platform APIs to offer excellent stability and longevity, and more generally for libraries that want to be relied upon to offer clear version information and backward-compatible updates. One question that one can ask, though, is whether one wants to experience that pain sooner or later. I am thinking of https://martinfowler.com/bliki/FrequencyReducesDifficulty.html https://martinfowler.com/bliki/FrequencyReducesDifficulty.ht... here. But what if you never have to experience that pain at all? Or if you can experience it only once, much later, when it really does become unavoidable, instead of experiencing a similar amount of pain multiple times along the way? Look at the sketch graph in that article, the one with time between actions and pain as the axes. Tell me what it means. Nothing. It means nothing. It conveys literally no evidence or data of any kind. And the entire argument rests on that non-existent foundation.
- rwj 6y ago
  Just one data point, but doesn't Google advocate for living at head? Long-lived software can't be static.
  - skybrian 6y ago
    Yes, and keeping up with these changes is a treadmill, for developers. They also statically link binaries, though, and an old binary could be in production for a while if the product isn’t being worked on. The popularity of Docker files shows another way of freezing dependencies. The general principle here is that changes get tested during the release process. You’re not creating new combinations of dependencies and running them in production without testing. (Well, within the same binary, at least. Servers talking to each other over the network may be unexpected combinations.)
  - Silhouette 6y ago
    But why should we take Google seriously as an example of good software development practice? For an organisation with effectively unlimited dev resources, it breaks things pretty often and kills off a lot of products outside of the star performers that support everything else. And thanks to the dominance of Chrome and Android, when Google does break things, the pain is shared by countless other developers as well. No-one can deny that Google has been a wildly successful business, but whether its current software development practices have anything to do with that or make it a worthy role model to emulate is a different matter.
    - rwj 6y ago
      Yes, take their lessons with a grain of salt, but they have a ton of experience, and shouldn't be dismissed out of hand either.
- majkinetor 6y ago
  > Nothing. It means nothing. It means that as time passes by, the things that need to be done accumulate and hence the pain of doing them. You don't need evidence for that. Its a common sense. Otherwise, give one example when waiting for action (and in absence of divine/external intervention) makes it easier. Via this logic we can deduce that there must exist 100% self-fixing entities. I am not aware of any such thing. Many entities have some autocorrection (including us) but up to a certain point and usually (only?) when life is involved.
MaulingMonkey 6y ago
Distro package managers implicitly pin versions too - at distribution granularity - updated randomly by a bunch of strangers downstream with limited testing. The result is incredibly poor. I deploy to consoles. I deploy to mobile. I deploy to the web via WASM. I deploy to windows as EXEs, MSIs, and APPXes. Your distro's linux package manager won't help me keep my dependencies up to date in any of these places. They won't even help me keep my dependencies up to date on linux, when the packages lag behind upstream - or in disconnected applications with no web access to update the linux distro with. How do I get security updates onto my OpenDingux RG350M? Through new images and newly built and pushed OPKs, not through fetched APT packages. With versions pinned upstream at the app source code level, I can actually see what versions I've shipped had a vulnerable version, and push updates / advise my users appropriately. Stale dependencies are admittedly a concern, but they're not a concern that's even remotely fixed by having an unpinned, floating version. There's a reason software started bundling auto-updaters, and it's not because linux distros were handling everything perfectly fine already. The article defends, among others, the Rust approach. Apps are pinned to exact versions via lockfiles. Libs are pinned to approximate verisons by semver, with CI typically catching when that breaks. This is a nice balance, and applies social pressure that encourages Rust projects to properly adhere to semver. Dependabot can flag dependencies with security issues, dependencies without security issues that are just old, auto-PR version updates to see if they pass CI or need manual action, and even auto-merge changes if you let it when the builds go green. I've used this article as an excuse to double check my settings. I didn't have dependabot enabled for a couple of private repositories. I have a few flagged issues in an offline, user-inputless, electron clock widget I keep on my windows desktop. Harmless... but if they hadn't been? This would let me know I need to rebuild, retest, and redeploy. Via push notifcation. Despite the bundling approximating static linking. Despite the lack of linux. Despite the complete lack of an OS package manager, or even proper CI scripts. It's a much more versatile and portable approach.
- rwj 6y ago
  I doubt that everyone is being as deligent as you. I suspect leaving security updates to upstream is not a recipe for secure distributions. For the record, I see both sides as having legitimate concerns.
pjmlp 6y ago
Nowadays? As long as I can remember all the work I delivered into production used some form of vendoring and I started during the ZX Spectrum heyday.

by cjfd 6y ago

Silhouette 6y ago

One danger is that dependencies are not getting updated regularly and one day one find oneself depending on a very old version of a dependency. That is only a problem if the old dependency no longer provides the required functionality, though. In many cases, that will never happen. The other is that it may not always be possible/practical for other people to be at the that exact version. Some libraries can depend on system libraries that cannot be easily upgraded. E.g., numpy depends on underlying system libraries and it is not always possible to choose whatever version. GUI-libraries ultimateley depend on system GUI-libraries which also, practically speaking, cannot be updated to any random version. Ironically, the problem you've described here originates with dependencies not having stable dependencies themselves. This is why it's so important for foundations like operating system or other platform APIs to offer excellent stability and longevity, and more generally for libraries that want to be relied upon to offer clear version information and backward-compatible updates. One question that one can ask, though, is whether one wants to experience that pain sooner or later. I am thinking of https://martinfowler.com/bliki/FrequencyReducesDifficulty.html https://martinfowler.com/bliki/FrequencyReducesDifficulty.ht... here. But what if you never have to experience that pain at all? Or if you can experience it only once, much later, when it really does become unavoidable, instead of experiencing a similar amount of pain multiple times along the way? Look at the sketch graph in that article, the one with time between actions and pain as the axes. Tell me what it means. Nothing. It means nothing. It conveys literally no evidence or data of any kind. And the entire argument rests on that non-existent foundation.

rwj 6y ago
Just one data point, but doesn't Google advocate for living at head? Long-lived software can't be static.
- skybrian 6y ago
  Yes, and keeping up with these changes is a treadmill, for developers. They also statically link binaries, though, and an old binary could be in production for a while if the product isn’t being worked on. The popularity of Docker files shows another way of freezing dependencies. The general principle here is that changes get tested during the release process. You’re not creating new combinations of dependencies and running them in production without testing. (Well, within the same binary, at least. Servers talking to each other over the network may be unexpected combinations.)
- Silhouette 6y ago
  But why should we take Google seriously as an example of good software development practice? For an organisation with effectively unlimited dev resources, it breaks things pretty often and kills off a lot of products outside of the star performers that support everything else. And thanks to the dominance of Chrome and Android, when Google does break things, the pain is shared by countless other developers as well. No-one can deny that Google has been a wildly successful business, but whether its current software development practices have anything to do with that or make it a worthy role model to emulate is a different matter.
  - rwj 6y ago
    Yes, take their lessons with a grain of salt, but they have a ton of experience, and shouldn't be dismissed out of hand either.
majkinetor 6y ago
> Nothing. It means nothing. It means that as time passes by, the things that need to be done accumulate and hence the pain of doing them. You don't need evidence for that. Its a common sense. Otherwise, give one example when waiting for action (and in absence of divine/external intervention) makes it easier. Via this logic we can deduce that there must exist 100% self-fixing entities. I am not aware of any such thing. Many entities have some autocorrection (including us) but up to a certain point and usually (only?) when life is involved.

MaulingMonkey 6y ago

Distro package managers implicitly pin versions too - at distribution granularity - updated randomly by a bunch of strangers downstream with limited testing. The result is incredibly poor. I deploy to consoles. I deploy to mobile. I deploy to the web via WASM. I deploy to windows as EXEs, MSIs, and APPXes. Your distro's linux package manager won't help me keep my dependencies up to date in any of these places. They won't even help me keep my dependencies up to date on linux, when the packages lag behind upstream - or in disconnected applications with no web access to update the linux distro with. How do I get security updates onto my OpenDingux RG350M? Through new images and newly built and pushed OPKs, not through fetched APT packages. With versions pinned upstream at the app source code level, I can actually see what versions I've shipped had a vulnerable version, and push updates / advise my users appropriately. Stale dependencies are admittedly a concern, but they're not a concern that's even remotely fixed by having an unpinned, floating version. There's a reason software started bundling auto-updaters, and it's not because linux distros were handling everything perfectly fine already. The article defends, among others, the Rust approach. Apps are pinned to exact versions via lockfiles. Libs are pinned to approximate verisons by semver, with CI typically catching when that breaks. This is a nice balance, and applies social pressure that encourages Rust projects to properly adhere to semver. Dependabot can flag dependencies with security issues, dependencies without security issues that are just old, auto-PR version updates to see if they pass CI or need manual action, and even auto-merge changes if you let it when the builds go green. I've used this article as an excuse to double check my settings. I didn't have dependabot enabled for a couple of private repositories. I have a few flagged issues in an offline, user-inputless, electron clock widget I keep on my windows desktop. Harmless... but if they hadn't been? This would let me know I need to rebuild, retest, and redeploy. Via push notifcation. Despite the bundling approximating static linking. Despite the lack of linux. Despite the complete lack of an OS package manager, or even proper CI scripts. It's a much more versatile and portable approach.

rwj 6y ago
I doubt that everyone is being as deligent as you. I suspect leaving security updates to upstream is not a recipe for secure distributions. For the record, I see both sides as having legitimate concerns.

pjmlp 6y ago

Nowadays? As long as I can remember all the work I delivered into production used some form of vendoring and I started during the ZX Spectrum heyday.