
How often to update third party libraries? - rabid_oxen
How often do you update your third party libraries? I have found that where I work we are a few versions behind on some python libraries.<p>As a follow up question, how do you ensure that there will be no unintended consequences? We have a ton of unit tests, but are there any additional recommended tests to do?<p>I am primarily using python, but I assume the same issues apply regardless of the language. I did some research and found a few things from over 5 years ago, so I wanted to see how the hacker news community solves this issue.
======
PaulHoule
I mostly program Java but I think the issues are similar with Python these
days.

I try to keep libraries up to date pretty regularly, probably checking for new
versions every one or two weeks, particularly when any area of the system
comes to my attention.

The worst problem, I think, is third party libraries that depend on other
third party libraries.

Last Friday, for instance, I was writing an AWS Lambda function and I found
that the libraries for writing a Lambda function depend on a certain version
of the SDK for Java core library that is three minor versions behind the
latest.

If you use another SDK for Java library that is at the wrong version, you're
going to end up with a mismatch between the core library and one or more of
the libraries that depend on the core library and this causes the
serialization system to fail at run time.

Another case is that the code for HDFS is stuck around Guava 11.0.2 whereas
Guava is at 19 these days. Updating things like that in the Hadoop code is
nasty since Hadoop is a house of cards that is barely held up by unit and
integration tests. Overall I find Guava, Jackson and Http-Commons are
responsible for the lion's share of breakage.

So I keep a list of libraries that I know are high risk and likely to have
problems.

As for "unit" testing, it depends what kind of tests you are writing. Strictly
speaking, the purpose of "unit" tests is to test your own code, not test your
dependencies. In fact, it's not unusual for unit tests to mock the
dependencies -- that is, test that your code calls the dependencies as
specified and that it reacts properly when it gets the responses from the
dependencies that you expect. This kind of test won't catch problems caused
when the behavior of the dependencies change.

Now a true "unit" test should run fast and not have a lot of baggage so there
is a case for it, but what does catch problems caused by version mismatches
are "integration" tests that typically are more of a pain to write and will
run a lot slower.

------
tedmiston
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
It 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.

------
tedmiston
Another point on upgrades is to make sure you're actually running the latest
subversion of Python 2.x / 3.x on your server(s).

------
RaitoBezarius
I use Dependency CI [1]. But to be honest, I have yet to benefit from alerts
on vulnerabilities in packages, etc…

[1] : [https://dependencyci.com](https://dependencyci.com)

