3 ms·

One of my biggest fights is getting people to use latest versions of high-quality software. More often than not, it avoids problems that are already resolved at

One of my biggest fights is getting people to use latest versions of high-quality software. More often than not, it avoids problems that are already resolved at tip. Helps discover newly introduced issues quickly and before it's a lot of trouble to fix them. Overall, I think it amortizes the cost of software development and reduces it on average, even if there are more smaller bursts where fixing work needs to be done, it's often trivial to do so. To that end, I even created Go Package Store [0] to make updating packages in one's GOPATH easier and more transparent. I use it at least once every few days to update my dependencies and deal with anything that comes up (rarely; most often I just need to leave a review comment on the fresh CL/PR). It's a great experience for me. Despite that, I have a feeling I might like MVS better than the traditional manifest+lock systems that try to pick the latest versions at project start time, but then keep them frozen there until people explicitly update. It makes people less likely to update on their own because they know a new project would start off with latest versions of dependencies anyway. With this system, you couldn't rely on that, and instead you have to update yourself explicitly from the start. I hope this knowledge gets people to take on that responsibility more often and makes it a good habit. Don't update when you need build stability, but when you have a quiet period and are able to update for some API changes, do so and reduce your tech debt for the future. > More than anything else, I wanted to find a version selection algorithm that was understandable. Predictable. Boring. Where other systems instead seem to optimize for displays of raw flexibility and power, minimal version selection aims to be invisible. I hope it succeeds. I'm keeping an open mind and looking forward to seeing how it works out. I have a feeling I might like it despite it seemingly optimizing for the opposite of what I fight for. I'm hopeful. [0] https://github.com/shurcooL/Go-Package-Store#readme https://github.com/shurcooL/Go-Package-Store#readme

snarfy 9y ago
It's OK as long as you are in charge of when the updates happen. Your system is good in that it is a manually triggered process. It becomes a problem when a full rebuild includes deleting external dependencies, downloading latest sources, and rebuilding everything. When that happens your build environment is a constant moving target. The problem grows exponentially with the number of dependencies you have. When you have a project with a 1000+ dependencies, all pulled latest, nothing will ever compile, let alone your own code.
- stouset 9y ago
  I semi-disagree. 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.
  - snarfy 9y ago
    If you've ever done web development and peeked into your node_modules folder you'll understand this is a serious problem.
  - KallDrexx 9y ago
    > 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. I'd argue dependencies should be manually updated constantly. While version pinning does allow you to accrue technical debt if your team has discipline it does allow you to manage the upgrade process and understand the impacts of a dependency upgrade. Even without obvious API changes it's possible that the implementation details of a library's method can cause your code to function differently, which can be caused by the introduction of a bug, the fixing of a bug your code didn't realize was a bug, or any minor quirks that may change between versions. When you manually upgrade you know exactly what to test and what to look for because (presumably) the person doing the dependency upgrade is someone who knows how the dependency is used. If you do not do manual upgrades but automatically update everything all the time bugs can sneak in and it won't always be easy to track down what caused it.
    - dionian 9y ago
      in my experience traceability of the versions of the dependencies used is as important as tracing that you use them... having that all in source control and being to replicate an immutable build from that tag at any time in the future is useful especially for large and complicated projects.

snarfy 9y ago

It's OK as long as you are in charge of when the updates happen. Your system is good in that it is a manually triggered process. It becomes a problem when a full rebuild includes deleting external dependencies, downloading latest sources, and rebuilding everything. When that happens your build environment is a constant moving target. The problem grows exponentially with the number of dependencies you have. When you have a project with a 1000+ dependencies, all pulled latest, nothing will ever compile, let alone your own code.

stouset 9y ago
I semi-disagree. 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.
- snarfy 9y ago
  If you've ever done web development and peeked into your node_modules folder you'll understand this is a serious problem.
- KallDrexx 9y ago
  > 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. I'd argue dependencies should be manually updated constantly. While version pinning does allow you to accrue technical debt if your team has discipline it does allow you to manage the upgrade process and understand the impacts of a dependency upgrade. Even without obvious API changes it's possible that the implementation details of a library's method can cause your code to function differently, which can be caused by the introduction of a bug, the fixing of a bug your code didn't realize was a bug, or any minor quirks that may change between versions. When you manually upgrade you know exactly what to test and what to look for because (presumably) the person doing the dependency upgrade is someone who knows how the dependency is used. If you do not do manual upgrades but automatically update everything all the time bugs can sneak in and it won't always be easy to track down what caused it.
  - dionian 9y ago
    in my experience traceability of the versions of the dependencies used is as important as tracing that you use them... having that all in source control and being to replicate an immutable build from that tag at any time in the future is useful especially for large and complicated projects.