You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'll start using the term "bump" instead of "upgrade," to reinforce that
increasing dependency versions does not strictly make things *better*.
It merely allows for that possibility while also introducing significant
risks of its own.
Highlights from my crappy review:
- bbolt had a couple changes, so that's interesting.
- Amazon turned the links in their doc comments into Go's new
Markdown-style links.
- Someone added zstd support to... something.
- Apparently Go supports z/OS (or at least x/sys/unix does).
- Those huge byte arrays in google.golang.org/protobuf scare the crap
out of me, as usual.
Seriously, I *DO* actually skim the vendor diff like this on EVERY ONE
OF THESE BUMPS; this is NOT the first time. I just don't usually bother
to comment on it, since it's not an especially deep review. The longer I
wait to look at these (to manage the risk of bad things happening), the
more work it takes to do even this light skim, and the less thought I
put into it.
Since this is a personal project, I've decided that the learning value
of keeping up with changes in the ecosystem and potentially finding
issues early (as unlikely as it is that *I'd* be the one to catch
something) outweighs the risks (of new bugs and vulnerabilities)
inherent in dependency bumps. This is not the same thing as "all
dependency bumps are good all the time." You may notice, for example,
that I do not have Dependabot PRs enabled for this repo (except by
mistake early on, in one PR that I overrode with a manual commit in the
same fashion as this one, albeit without this level of commit message).
But, yes, I've been lax on terminology, and "upgrade" is not the right
term to use. So I am fixing that part of the process, at least.
0 commit comments