Hacker News Reader

I agree that taking the latest package every time you're building for production deployment is a bad idea. And version pinning in and of itself doesn't really solve this problem either: if you're relying on an external source for reproducible builds, you've got a potential point of failure. To have a reproducible build you need to have access at the time of the build to the specific artifact you want to include in the build, which at the end of the day means having that library at hand locally as part of your build system. We don't have great stories yet about how to maintain these artifacts locally: setting up your own repos for many ecosystems isn't a walk in the park.

Specifying a version does allow you to know which artifact to include, but that's at the artifact level, which often is conflated with the particular library that artifact provides. A build number or other included in the artifact gives you the same selection properties, yet is independent of the code the artifact actually provides. Currently code and artifact are labelled similarly, but that's more a purposeful accident rather than a guarantee or deterministic property.

As for the package-3, package-4 thing you mention, I agree, it's kind of a mess. I think that's more a result of this lack of separation between the code and the artifact (if I'm understanding you correctly), and module (what is referenced in the code itself namespacing and aliasing. I don't think it's a solved problem.

> And version pinning in and of itself doesn't really solve this problem either: if you're relying on an external source for reproducible builds, you've got a potential point of failure

I grammerred badly, but this is what I meant when I said:

"As you keep an onsite cache of the packages"

In Nuget land this is quite easy but then you have some housekeeping to ensure the copy of the packages is backed up. This could be done with a separate source repo if you want to use that hammer.

You can vendor dependencies if being reliant on a package service is too unreliable.

Yes, that's definitely another option. Once you've done this, you've effectively added the code to your application, with the hope that it might be possible to have a drop-in replacement in the future.

> I would find it annoying to use this scheme because you have to hunt around searching in a different way to look for major upgrades compared to what you do for minor ones.

Either way, a major upgrade would mean a significant change in the way you use the API in your project.

Not always. A breaking change is just that, it doesn’t mean a wholly incompatible re-imagining. It’s possible to upgrade major versions without any actual code changes.

The proposal is to pin the major version and always use the latest minor version.

Assuming no accidental breaks of backwards compatibility in minor versions, this should work.