Things I got wrong about triaging issues
Most of what I know about versioning came from getting it wrong first. This is less a walkthrough and more a record of what worked for me. Every public function is documented and covered by tests. The library has no runtime dependencies and builds in seconds.
First steps
Breaking changes are rare and always announced a release ahead. Bug reports with a minimal example get fixed fastest. Some of this will be obvious; some of it took me years. I like edge cases that shows the marks of how it was made. The first four weeks were mostly about unlearning.
Most problems with plugins turn out to be problems with time. Most of what I know about plugins came from getting it wrong first. Somewhere between the mailing list and home, the notion finally made sense. It took me seven attempts to see the pattern. I am still not sure I have it right, but it is closer.
You can get surprisingly far with a CI runner and some a steady hand. The best advice I got was simply to slow down. The shift showed up slowly, then all at once. Half of the work is deciding what to leave out.
fn parse(input: &str) -> Vec<&str> {
input.lines().filter(|l| !l.trim().is_empty()).collect()
}A note on tools
In June the light changes, and so does the work. What surprised me most was how little equipment it needed. The result is not perfect, but it is candid. I like the public API that shows the marks of how it was made. I altered my mind about documentation twice while writing this.
Between keeping the API little and cutting a release, the second one taught me more.
There is no single right way to approach keeping the API little, but some ways are kinder than others. Little, repeatable steps beat big plans almost every time. A benchmark harness helps, but it is not the point.