10 Years Since grunt-semantic-release: More of What Neighbourhoodie Got Up To posted Wednesday, August 13, 2025 by The Neighbourhoodie Team news
We recently shared a blast from the past with a 10-year-old Neighbourhoodie update back from when we were working on Greenkeeper, a first-of-its-kind dependency automation service. These are commonplace now, but at the time we were working on it, dependency management very much belonged to a manual world. The software release process also doesn’t resemble today what it did 10 years ago.
Not all release activities sparked joy, to use a tidying-up metaphor that feels appropriate for this dig through history. So we decided to take out what didn’t. The article below from Stephan Bönnemann first appeared on the Hoodie blog in September 2014, and was our way to share grunt-semantic-release (which has since graduated to become a whole ecosystem), an npm module our team remains proud to have originated.
Almost all of the properties linked in this article remain available, even if they don’t see much activity these days. What is unavailable has been marked.
tl;dr: Don’t release 💾 like a 🐒, as it causes lots of 🐛🪲. Do it like a 👸 using 🐗🎈. Use the 🕑 saved and the 💰made to 💞: grunt-semantic-release.
This is how easy it is to release software now. Yes, checkboxes are pre-checked for you.
Before that at Hoodie’s: …
- I begin with changing the version number in the ‘package.json’, which is not in sync with the ‘bower.json’, because obviously someone messed that up last time. Okay, just commit and tag this with the new version. But wait, should I use the ‘vx.y.z’ or the ‘x.y.z’ pattern? There were so many discussions about this, I am just confused. It had never been consistent anyways, so I just continue with pushing something. I forgot to use the ‘—tags’ flag though. Luckily, I noticed immediately and the last step is just ‘npm publish’.
- Done?
- Five minutes later, I realise the Travis CI build failed. I have invested an entire week to ship a new feature and now everything falls apart, because releasing a new version means I have to remember a gazillion steps and execute them in the exactly right order.
This happened approximately once a week at Hoodie, especially as we are currently maintaining over 50 repositories. You can probably imagine how messed up things can get when a lot of different people have to follow this fragile, lengthy and awfully repetitive process:
The old process looks simple, but due to multiple human interactions it is error-prone.
At some point I was so fed up with this that I defined our requirements for a solid new process. It should be
- automagic
- supportive
- forgiving and
- bring back the fun and excitement of a software release.
Our requirements
- Simplicity: One and only one simple command to execute
- Maintainability
- Seamless integration with our current grunt setup
- Zero to no setup to make it maintainable with 50+ repositories
- Consistency 3. Never release a module when the build/tests fail 4. When the build fails there should be no need to rewrite git history 5. Implicit SemVer compliance
- Permissions: Everyone with push access should be able to release
- Communication 6. Automatically generate a changelog 7. Make the changelog available on git/GitHub releases
- Fun: Gimme animated gifs
Existing solutions
There are quite a lot of (grunt) plugins that evolve around releasing software but except for 1, 4 and 5.1 nothing is solved to our satisfaction and above all not out of the box. So for example 1 is solved by grunt-bump, 4 is solved by Travis CI deploy hooks and 5.1 is solved by angular’s commit message guidelines and conventional-changelog, but it would already take forever to set this up for some of our modules and it doesn’t even cover 50% of our requirements.
The Hoodie Way: our own solution
This is why I decided to build a layer on top of the existing tools that solves all the remaining issues, but at the same time incorporates and configures the existing ones. Let’s have a look at the new workflow.
All I have to do locally now is type ‘grunt release’ into the terminal. The task will analyse the changes made since the last release and suggest the next version – and that’s it already. Once I confirm, everything is taken care of by bots. No more error-prone humans necessary.
The new process is complex, but automated and taken care of by bots.
Instead of running the build and generating the changelog locally as before, this only tags the current ‘HEAD’ with ‘release-x.y.z’ and pushes it. On Travis CI, a special deploy hook recognises this, generates the changelog, runs the build (and everything else you want it to do) and finally creates a release commit with all the changes. This is important because Travis CI is a neutral environment where everything is freshly installed. No more “But it works on my machine”. As soon as this is pushed back to git, yet another run on Travis CI will finally publish to GitHub releases and e.g. npm. But you can basically configure every deployment target Travis CI has to offer.
As this is packaged in a single grunt plugin including an interactive setup script, it’s easy to setup a lot of modules and release them all in exactly the same way. There is no more confusion about tagname-patterns and it’s straight-out impossible to publish a broken build. I even managed to cover 6 – the fun part. Every time a new version is about to be released, a random superb-animal-codename is generated and, using the Giphy API, a matching animal gif is appended to the release body. [Unfortunately, the precise animal gif in question has been lost to time. We hope this stand-in pleasantly punctuates your reading experience as originally intended.]
Get this for your own package
Obviously, the whole plugin was initially tightly coupled to the needs of Hoodie, but I extracted a general-purpose gruntplugin and published it to npm (using itself) last week. Say hello to grunt-semantic-release, or say hi to its repo on GitHub.
Join the discussion!
This module aligns with our efforts to provide essential tooling for a small modules world. Another one we built with this goal in mind is Ubersicht.
We would love to hear your thoughts, not only about grunt-semantic-release, but about tools you (would love to) have for your work as module author. Chime in on the discussion in the comments, on Hoodie’s or my personal Twitter or in the Issues. [We’ve left these legacy handles here because these profiles still exist, though inactive. You can follow both Stephan Bönnemann and Neighbourhoodie on Mastodon.]
Thank you for coming along with us down this corridor of Neighbourhoodie history. We hope you enjoyed time-traveling with this and the last Hoodie post. You can keep up with our current work by joining our newsletter, or checking out our CouchDB-focused products and services.
« Back to the blog post overview