4 ms·
I wrote a function in Fabric that upgrades one package at a time to the latest version, commits it on a dedicated branch, and pushes to the git server. If the
by tedmiston 10y ago
I wrote a function in Fabric that upgrades one package at a time to the latest version, commits it on a dedicated branch, and pushes to the git server.
If the unit tests pass, we continue with it and do additional manual testing as might be necessary. The manual testing is pretty library specific, but for example, upgrading requests I might check that SSL seems to be working fine; upgrading pytz, I might check for weird timezone edge cases. It's nice to have a dedicated QA / staging server that you can do this on. The best advice I can give is to do it frequently. Small upgrades are easier than big jumps, also, not every package uses semantic versioning, so while breaking backwards compatibility is rare, I'd say it happens with 10–15% of libraries in my experience (mostly building APIs and web apps).
- tedmiston 10y agoIt might be useful for me to add a polar opposite perspective here too — I have one (senior engineer) friend who, for personal projects, does not pin dependency versions at all. In other words, his requirements.txt looks something like: django requests Instead of: django==1.9.9 requests==2.11.0 I can't recommend it for production projects, but it is a curious way to force yourself to live on the edge. Still, I would encourage pinning specific versions when you go from local environment to prod.