4 ms·

Yet another package management "advice" article from the point-of-view of a developer and not a maintainer. You try maintaining an ecosystem where every depend

Yet another package management "advice" article from the point-of-view of a developer and not a maintainer. You try maintaining an ecosystem where every dependency constraint is a hard specific version. You'll spend 80% of your time fiddling with bumping versions. Fuck that shit.

k__ 9y ago
Well, someone has to do the work. But version pinning is probably the best way at the moment. This way the maintainers can use ranges and the developers can pin what they really need in the end-product. There are more developers than maintainers, so this scales much better.
- eeZah7Ux 9y ago
  > There are more developers than maintainers, so this scales much better. Wrong comparison. The majority of software is built, deployed, maintained and used by entirely different organizations over years. Companies doing end-to-end CD and running their software only internally are the minority. This kind of bad practices from few developers turns into countless hours of work to maintain systems years later.
mrweasel 9y ago
It also completely ignores security issues. It's worthless to require a library or package be a specific version number, if that version is behind on security fixes. Yes, the developer might like a library, middleware, application server or whatever to be a specific version, but that ignores that in a production environment you can be behind on security fixes. It's completely reasonable to lock your code a specific major release of some dependency, assuming it's still being patched, but minor release should be something your patch management solution just applies. From an operational point of view, I think the original approach of Go, where HEAD of a dependency was just pulled from the repository of the dependency, is the right way to go. If something break, you fix it, because it needs to be done a some point anyway. I see this all the time with Java middleware. Some developer specifies that we need JBoss version X.Y.Z and not patch unless they say so. At the same time we're required to patch the operation system with the latest security patches. Well what's the point of that if the only service exposed to the Internet is the only thing not being patched?

k__ 9y ago

Well, someone has to do the work. But version pinning is probably the best way at the moment. This way the maintainers can use ranges and the developers can pin what they really need in the end-product. There are more developers than maintainers, so this scales much better.

eeZah7Ux 9y ago
> There are more developers than maintainers, so this scales much better. Wrong comparison. The majority of software is built, deployed, maintained and used by entirely different organizations over years. Companies doing end-to-end CD and running their software only internally are the minority. This kind of bad practices from few developers turns into countless hours of work to maintain systems years later.

mrweasel 9y ago

It also completely ignores security issues. It's worthless to require a library or package be a specific version number, if that version is behind on security fixes. Yes, the developer might like a library, middleware, application server or whatever to be a specific version, but that ignores that in a production environment you can be behind on security fixes. It's completely reasonable to lock your code a specific major release of some dependency, assuming it's still being patched, but minor release should be something your patch management solution just applies. From an operational point of view, I think the original approach of Go, where HEAD of a dependency was just pulled from the repository of the dependency, is the right way to go. If something break, you fix it, because it needs to be done a some point anyway. I see this all the time with Java middleware. Some developer specifies that we need JBoss version X.Y.Z and not patch unless they say so. At the same time we're required to patch the operation system with the latest security patches. Well what's the point of that if the only service exposed to the Internet is the only thing not being patched?