Release notes: dependency-free defaults

Jul 19, 2025

It is not glamorous, but it holds up. Somewhere between the mailing list and home, the notion finally made sense. Half of the work is deciding what to leave out. Breaking changes are rare and always announced a release ahead.

Getting started

The first nine weeks were mostly about unlearning. In November the light changes, and so does the work. Below are a few observations, roughly in the order I learned them.

def build_tasks(path):
    """Build tasks from a file, skipping blank lines."""
    with open(path) as f:
        return [line.strip() for line in f if line.strip()]

What did not work

I keep a short list of things to try next; benchmarking is near the top. Most of what I know about documentation came from getting it wrong first. If you only take one thing from this, make it the part about edge cases. Bug reports with a minimal example get fixed fastest.

There is no single right way to approach cutting a release, but some ways are kinder than others. If something here is unclear, that is on me, not you. Here is what altered, and what stayed exactly the same.

• Note the date and the weather
• Revisit plugins after a week
• Give benchmarking a full autumn
• Keep a benchmark harness within reach
• Start with versioning and nothing else

First steps

For a long time I treated versioning as an afterthought. The API is intentionally little so that it can stay stable. It took me nine attempts to see the pattern. The library has no runtime dependencies and builds in seconds.

What surprised me most was how little equipment it needed. I altered my mind about the command line twice while writing this. I altered my mind about releases twice while writing this.

For a long time I treated releases as an afterthought.

A note on tools

Most of what I know about versioning came from getting it wrong first. None of this is new, and that is partly why it works. The stable part is hardly ever the hard part; consistency is. The result is not perfect, but it is candid. Most problems with the public API turn out to be problems with time.

Good versioning is mostly a series of little, unglamorous decisions. The fast part is hardly ever the hard part; consistency is. I am still not sure I have it right, but it is closer. The shift showed up slowly, then all at once. Some of this will be obvious; some of it took me years.

Every public function is documented and covered by tests. I like the public API that shows the marks of how it was made. Most problems with edge cases turn out to be problems with time. I keep a short list of things to try next; keeping the API little is near the top. Somewhere between the issue tracker and home, the notion finally made sense.

You can get surprisingly far with a fuzzer and some a steady hand.