After seven and a half months of churn, the Spernakit template - the foundation every one of my apps is built on - got a long-term-support stamp today: v3.8.0-lts.
Up until now, Spernakit has been in a constant state of refinement, a tweak here, a polish there, with changes landing almost every day. That’s fine when you’re still figuring things out, but it’s exhausting when what you actually want to do is build apps. So today I locked it down. I pinned every library to an exact version, replacing the semver ranges, and wrote down what would justify a change (basically: security holes only). I also added guards against changes to the locked baseline. Then I tagged it and pushed.
The plan was already drawn up from yesterday, so today was mostly execution: ship the policy doc, write the guard scripts, capture the quality baselines, run the smoke tests, tag, push. There was a small comedy moment where my own brand-new “no lockfile changes allowed” guard tried to block me from committing the dep-pinning lockfile change itself. Doing exactly its job, to be fair. I had to flip the override flag to get past my own gate on day one.
The derived apps will pick up the new version the next time they sync and keep working as before. If a real bug shows up, it will be fixed on the LTS line as a 3.8.x patch.
Later update: The freeze lasted less than two months. Five minor releases followed the LTS tag; one, 3.11.0, was explicitly flagged as an exception. On June 30 I removed the baseline snapshots, lockfile guard, and surface-diff policy entirely. I still think the decision made sense on May 5. By the time I was preparing to go public, the policy was getting in the way.