Giving the project an address it can keep

0.9.0 is the release where Nibble got a home: the code on GitHub, and the project at nibble.ink. It sounds like a config change. It was mostly a lesson about addresses.

Where do release notes come from?

The Control Plane has an Updates screen. It shows which release a site runs, and the notes for anything newer. Until this release, it read those notes from a raw file inside a git repository. That works, right up until the repository moves.

So the notes moved behind an address this project controls: a small JSON API on nibble.ink. The notes themselves didn't change. What changed is that the address is now one I can keep serving wherever the code ends up living.

The release that can't know

Here's the part that caught me out. The upgrade command reads where to fetch releases from out of the version you already have. So the upgrade that brings in the new address still asks the old one, because the old release is the one asking.

There's no clever fix for that. A release can only know about the world as it was when it was cut. So the upgrade note for 0.9.0 says it plainly: run the upgrade once with the new address spelled out, and every upgrade after it finds its own way.

Generated, not appended

The feed used to be written by appending to it. Now it's generated from the changelog every time a release is cut, so it can't drift from what the changelog says. One source of truth, and the feed is a view of it.

Small lesson, written down so I don't relearn it: anything a released version reads at runtime is a contract with the future. Pick those addresses as if they have to last forever, because for somebody's install, they do.