Technology
Releases when in a hurry

Recently I made the (in hindsight costly) mistake of trying to push out a release in a hurry. It ended horribly. TL;DR: Don’t rush, especially when you’re releasing software.

Warning: this blog post contains self-criticism.

Some time ago I suddenly noticed a lot of interest in one of my projects. A lot more feature requests and GitHub pull requests were added. Some people were really waiting for some of these improvements, so a release had to be pushed out soon.

One evening I sat down and decided to get it over with when I noticed a new issue posted describing a bug. I decided to postpone the release until the bug was fixed.

A couple of days later I really wanted to push out the release quickly. I accepted the pull request which was supposed to fix the bug, ran a quick test on my own machine and published the new code on the Python package index. So far so good, although I distinctly remember thinking:

There is no unit test for this feature, but the code seems good, so it’s probably not going to break.

And even if it does, we can always add a regression test then.

(in a moment of weakness)

Oh was I wrong.

I should have known, using words like ‘probably’ and ‘seems’ usually indicate something iffy.

Quickly after that I received word from one of the people who where eagerly waiting for the release that it did not work. Travis CI showed all greens, and it worked locally.

As it turned out the fix worked only on Django 1.11 and higher, which was at a first alpha release at that moment. The only reason I was running that locally was to test the library with this version. Travis did not find any errors since no unit test covered a request to the Django admin integrations, in which the fault occured. The universe clearly did not want me to get away with having no test.

One quick fix and release later everything was fine again, but it did remind me of two important things:

1. Never think something is going to work until you have actually tested it properly.
2. Never rush a software release.

Since all of this happened on an open source project the evidence will be there forever. To make it a bit easier for you, the reader, I will point you to this release, this issue and this subsequent release.

In the end the damage was not massive since a fixed version was released less than half a day later. At the typical rate at which people tend to update Python packages there was no real impact, other than those few people waiting for the release (probably just the one guy which reported it as broken).

End good, all good.