Release 0.23.0
An upgrade that asks first
I built the upgrade path to be quiet, and I think that was the wrong call.
Chief of Staff keeps everything it knows about you in plain files in a folder you own. That is the whole promise, and it has a consequence I underweighted. A release can rename a field, retire a convention, or make a file mean something slightly different than it did last month, and the files it would be adjusting are the ones you wrote. For twenty-two releases the first session after an update simply handled that. It ran a migration pass, applied what it could, asked only where a step happened to demand it, and most of the time you never learned your memory had been touched.
Nothing broke. I still think it was wrong, because “nothing broke” is a claim I could only make about the cases I went and looked at.
The whole set, in one exchange
Now the first session after an upgrade works out the span it is bridging: the release your memory was last aligned with, through to the one you just installed. It reads what changed across that window, checks which of those changes apply to your folder, and if any of them would alter something you wrote, it puts the whole set to you at once and waits.
Two things I care about in that design. It is one exchange, so you are not answering prompts all morning. And declining is cheap. Say no and it asks again next session, so turning it down once doesn’t cost you a clean folder or earn you a permanent nag.
If nothing applies to your folder, it says nothing and gets on with the day. Its own bookkeeping, noting which release your memory now matches, never needed your permission and still doesn’t ask for it.
It stopped depending on my discipline
The migration pass used to rely on each release carrying a note that said “this one touches memory.” I write those notes. In 0.15.0 I removed a field from every team member’s charter and did not write one, and the pass walked straight past the change it existed to catch.
So it reads the release entries themselves now instead of waiting to be told. I would rather the mechanism not depend on me remembering something at release time.
The bug underneath
Whether your memory needed migrating at all was decided by comparing two version numbers as text.
Compared that way, 0.9.0 looks newer than 0.10.0.
The effect was invisible and exactly backwards. The oldest installs, the ones with the most history to bring forward, were the ones the pass declined to run on. Nothing said so, because from the inside everything looked current.
I could be wrong about the one exchange being the right shape. If it turns out people would rather approve these one at a time as they come up, that’s a small change to make. My guess is that a single set you can read in one go is easier to say yes to, but it is a guess.
The rules behind all of this are published in full. How updates work has the upgrade rules, and How it works is the place to start if you have not read any of them.