Fixed this :)
20 hours ago
3
2
1
0
Posts by Andrew Nesbitt
Andrew does a better job than we do at walking through the features of npmx.dev. We need to set up a resources page to link to these kinds of posts. If you care about registries, ecosystems, and open source, queue every single one of Andrew's posts to your reading list.
5 days ago
37
2
1
0
we're having a little npmx social tonight in London! come join us for conversation, food, beer, and stickers 🥳
guild.host/events/npmx-...
5 days ago
33
10
1
1
Common Package Specification: Not the cross-ecosystem format the name suggests.
nesbitt.io/2026/04/13/c...
1 week ago
1
1
0
0
Package Registries and Pagination - 100MB of metadata for 10,451 versions: nesbitt.io/2026/04/10/p...
1 week ago
0
0
0
0
Following on from yesterdays post about package security problems for AI agents, here's some potential defenses: nesbitt.io/2026/04/09/p...
1 week ago
0
0
0
0
Advertisement
I had a chat with @andrewnez.bsky.social about why creating a new package repository is so hard. There are a ton of little details like support from SBOM and vulnerability scanners nobody even thinks about. There are so many little details
Andrew does a great job explaining all this and more
2 weeks ago
5
1
0
0
![screenshot of the first page of my “Stamp It! All Programs Must Report Their Version” blog post:
Recently, during a production incident response, I guessed the root cause of an outage correctly within less than an hour (cool!) and submitted a fix just to rule it out, only to then spend many hours fumbling in the dark because we lacked visibility into version numbers and rollouts… 😞
This experience made me think about software versioning again, or more specifically about build info (build versioning, version stamping, however you want to call it) and version reporting. I realized that for the i3 window manager, I had solved this problem well over a decade ago, so it was really unexpected that the problem was decidedly not solved at work.
In this article, I’ll explain how 3 simple steps (Stamp it! Plumb it! Report it!) are sufficient to save you hours of delays and stress during incident response.
[…]](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:eb3563jmh2vjnrlkwujxqdwg/bafkreibmyjp2vprkz3vd4quze4ptlmt5sgz32mjc2bycogzwu6ps2odxpq)
screenshot of the first page of my “Stamp It! All Programs Must Report Their Version” blog post: Recently, during a production incident response, I guessed the root cause of an outage correctly within less than an hour (cool!) and submitted a fix just to rule it out, only to then spend many hours fumbling in the dark because we lacked visibility into version numbers and rollouts… 😞 This experience made me think about software versioning again, or more specifically about build info (build versioning, version stamping, however you want to call it) and version reporting. I realized that for the i3 window manager, I had solved this problem well over a decade ago, so it was really unexpected that the problem was decidedly not solved at work. In this article, I’ll explain how 3 simple steps (Stamp it! Plumb it! Report it!) are sufficient to save you hours of delays and stress during incident response. […]
![screenshot of the last page of my “Stamp It! All Programs Must Report Their Version” blog post:
Conclusion: Stamp it! Plumb it! Report it!
My argument is simple:
Stamping the VCS revision is conceptually easy, but very important!
For example, if the production system from the incident I mentioned had reported its version, we would have saved multiple hours of mitigation time!
Unfortunately, many environments only identify the build output (useful, but orthogonal), but do not plumb the VCS revision (much more useful!), or at least not by default.
Your action plan to fix it is just 3 simple steps:
Stamp it! Include the source VCS revision in your programs.
This is not a new idea: i3 builds include their git-describe(1) revision since 2012!
Plumb it! When building / packaging, ensure the VCS revision does not get lost.
My “VCS rev with NixOS” case study section above illustrates several reasons why the VCS rev could get lost, which paths can work and how to fix the missing plumbing.
Report it! Make your software print its VCS revision on every relevant surface, for example:
[…]](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:eb3563jmh2vjnrlkwujxqdwg/bafkreie44kyf3bi262fe6se54yj26txtvxmx6dwqk6jrtqhum7a7is2gs4)
screenshot of the last page of my “Stamp It! All Programs Must Report Their Version” blog post: Conclusion: Stamp it! Plumb it! Report it! My argument is simple: Stamping the VCS revision is conceptually easy, but very important! For example, if the production system from the incident I mentioned had reported its version, we would have saved multiple hours of mitigation time! Unfortunately, many environments only identify the build output (useful, but orthogonal), but do not plumb the VCS revision (much more useful!), or at least not by default. Your action plan to fix it is just 3 simple steps: Stamp it! Include the source VCS revision in your programs. This is not a new idea: i3 builds include their git-describe(1) revision since 2012! Plumb it! When building / packaging, ensure the VCS revision does not get lost. My “VCS rev with NixOS” case study section above illustrates several reasons why the VCS rev could get lost, which paths can work and how to fix the missing plumbing. Report it! Make your software print its VCS revision on every relevant surface, for example: […]
New blog post 🥳
Stamp It! All Programs Must Report Their Version
In this article, I’ll explain how 3 simple steps (Stamp it! Plumb it! Report it!) are sufficient to save you hours of delays and stress during incident response.
Read more: michael.stapelberg.ch/posts/2026-0...
#nix #golang #linux
2 weeks ago
11
3
2
0
The Cathedral and the Catacombs - Stretching a metaphor deep into the floor.
nesbitt.io/2026/04/06/t...
2 weeks ago
0
0
0
0
Advertisement
One of the strengths of Homebrew, despite it being unpopular, is being willing to break backwards compatibility when necessary.
NPM’s unwillingness to do so reflects GitHub’s: both show excessive caution that harm both security and usability.
2 weeks ago
13
4
0
0
Turns out my blog was featured on a rather popular youtube channel: www.youtube.com/watch?v=DAHZ...
3 weeks ago
4
0
0
0
Advertisement
Captain America sat backwards on a chair like a camp counsellor
So your boss built a prototype on the train...
mynameismartin.co.uk/blog/your-bo...
4 weeks ago
24
6
0
1
How to Attract AI Bots to Your Open Source Project: nesbitt.io/2026/03/21/h...
(This post was contributed by an ai bot)
4 weeks ago
8
1
1
0
Nerd sniped again, this time by @miketheman.com, into looking at how various package managers do mirroring: nesbitt.io/2026/03/20/p...
1 month ago
8
2
0
0
Me too, some of the biggest I’ve ever seen this past couple weeks
1 month ago
1
1
1
0