This is a weblog about computing, culture et cetera, by Miikka Koskinen. Read more.
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
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.
- When to create a release?
- How much should the version number be incremented?
- 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:
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!”
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 community , 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?
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.
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:
- 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.
- Inspiring talks. These make you want to do things and do them well.
- Toolbox talks. These talks give you actionable ideas to use in your work.
Great if the ideas are new to you, potentially boring otherwise.
- 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.
- Tara Ojo’s talk on mentoring junior developers. I’ve heard so many stories
about early-career people getting hired but then forgotten by the company.
Without help and guidance, there’s a big chance that they won’t succeed and
then they either leave or get fired. This is waste of everybody’s time. See
Tara’s slides, she has good suggestions on what to do.
- Alicia Liu’s talk on how to navigate your job when you get promoted to a new
management position and have no idea of what you’re doing.
- Kevin Goldmiths’s talk on techniques for 1:1s, team meetings, etc. I haven’t got
much experience with these, but his methods sounded good. See Kevin’s slides.
- Jenny Duckett’s talk on how to build sustainable teams. There was way too much
information for me to process in one go, but what stuck with me was that you
and your team should make a habit of sharing information about your work
frequently to prevent the silo-ing of knowledge. For example, actually write
down why you decided to do something. See Jenny’s slides.
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
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:
- Live captioning. All the talks were captioned live: next to the big screen,
there were smaller screens where the stenographer’s text was projected.
Obviously this helps the people with hearing difficulties, but it’s great for
everybody. If you lose the context for a second or if the speaker uses weird
words, you can look at the captioning and get back on track.
- Speaker office hours. Instead of a Q&A session after each talk, there was a
room where you could meet the speakers during the break after their talks and
ask them questions. The one-on-one conversations were interesting and you
didn’t have endure any “this is more of a comment than question” takes.
- They played kick-ass music when the speakers entered the stage. Really gave me
feeling that we’re now going to hear from an amazing person. I assume it made
the speakers feel cool, too.
- They had a quieter chill-out area. There were guided mindfulness sessions, and
while I’m not into guided meditation myself, the sessions ensured a peaceful
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.