This is a weblog about computing, culture et cetera, by . Read more.


Fully automated releases

Have you ever contributed a patch to an open-source project, got it merged, and then waited months for a new release that would include your patch? Me too, reader, I’ve been there.

Moreover, I’ve been the maintainer who hasn’t gotten around to cutting a release. Cutting releases is a chore. Usually it’s a fragile, multi-step process that is not especially fun.

As programmers, what is our answer to fragile, multi-step processes? We automate them.

How to do it

When creating a release, there are a couple of steps where human input and human judgement is needed.

  1. When to create a release?
  2. How much should the version number be incremented?
  3. What to write in the change log?

There’s an automation-enabling answer to the first question that is familiar for many developers from their work environment: embrace continuous delivery and continuous deployment. Each pull request should leave the project in a state where it can be released. Then you can automatically create a release every time you merge a pull request.

You still need a human to answer the second and third question, at least if you have a conventional versioning scheme. To move the burden away from the maintainer, you can ask the contributors to fill in this information during the contribution process.

I know of two actual implementations of this: Hypothesis continuous release process and semantic-release. Hypothesis asks you to include a special file in your pull requests that looks like this:

RELEASE_TYPE: minor

This release adds a function for printing the text "Hello, world!".

semantic-release relies on specially-formatted commit messages:

feat(core): add function for printing ”Hello, world!”

Here feat means this commit adds a new feature, implying a minor release if you’re following Semantic Versioning.

In both cases, after a pull request has been successfully merged, the CI server will read this information, update the change log, increment the version number, and push a new release to the package manager. As a contributor this means that if your patch gets merged, it will be released.

What about Clojure?

I’m not aware of anyone doing this in the Clojure community1 , but I believe it would be beneficial. There are a lot of small projects that would get contributions but the maintainers are not around to merge and release them. Automated releases would make the work of the existing maintainers easier and it would also make it simpler to onboard new maintainers.

I have implemented a proof-of-concept version of the Hypothesis process for cache-metrics, a small library of mine, but I haven’t yet dared to introduce it to any ”real” libraries. Many actively developed projects would need to change their ways of working as you couldn’t just merge or commit random things to master.

I hope this post acts a starting point for a discussion. What do you think?


  1. cljsjs/packages kind-of does it, but it is a a package repository and not a library.


Migrated to Hugo

After five years of using Hakyll to generate this site from a bunch of Markdown files, I finally migrated to Hugo. Hakyll is pretty cool, but using it makes only sense if you’re using Haskell for other stuff as well. I haven’t touched Haskell lately. Alas. Hugo has everything I need built-in and seems to work well enough.

I’ve tried to keep all the important URLs same or add redirects when that is not possible. Feed readers might do something weird with the updated feed, though. Sorry about that. If something is broken, please let me know.


Lead Developer London 2018

The opening of The Lead Developer London conference.

Last week, I attended The Lead Developer conference in London. It’s a conference about being a technical lead. The talks were a mix of general leadership advice (it’s all about feedback!), tech lead specifics (focus on the high-impact stuff in code reviews!), tech (ReasonML is cool!), and self-help (remember to exercise and meditate!).

I decided to attend the conference because I’ve ended up taking on some tech lead responsibilities and I’ve felt that I don’t know what I’m doing. Spending two days listening to talks about tech leadership seemed like a good idea.

The talks repeated the fundamentals: getting and giving good feedback is a key activity, you need to have empathy, and you need to be able to articulate why you’re doing things in addition to how. The hard part, of course, is putting these ideas in action.

The most interesting talks

I have this taxonomy of conference talks that I like. It subjective since it depends on what you already know. Here it is anyway:

  1. Clarifying talks. These do not necessarily teach you new things, but they make you see the things you already know more clearly and connect them to other ideas.
  2. Inspiring talks. These make you want to do things and do them well.
  3. Toolbox talks. These talks give you actionable ideas to use in your work. Great if the ideas are new to you, potentially boring otherwise.
  4. Tour talks. These talks walk you through a topic by covering a lot of ground with way too many details in way too little time. The audience might get confused, but I like that.

Here are my highlights from the conference in each of the categories. Unfortunately the videos haven’t been published yet.

Clarifying talks:

Inspiring talks:

Toolbox talks:

Tour talks:

On the event

Usually the conferences I go to have been organized by people who are not professional event organizers. The Lead Developer conference is organized by an event organizing company and it showed in a good way: everything was smooth.

My only complaint is about the venue. The lobby was so noisy during the breaks that it was hard for me to hear what people were saying. This obviously makes having a conversation hard and so I didn’t get much of talking to people. Otherwise the Barbican Arts Centre was a pretty good venue. Even though there were something like 1100 attendees, it didn’t feel crowded at all.

Some nice touches that would be cool to see at other conferences:

In general, I’d recommend the conference if you’re the kind of person who likes conferences, you’re interested in this topic, and your employer foots the bill.


For more posts, see archive.