Jon Pretty

It's difficult enough to keep compatibility across versions when you're programming against a public API. With tests, you often want to check internals.

Oh, you wouldn't, but the fact it's hard at the moment is sort of the point: If the tests aren't in sync with your main repo, then some of them would just fail (at compile time). You would update them if/when you care enough to do so, but no requirement for it to be synchronous.

By the way, everything I'm saying about tests could be applied to documentation too. It's maybe more understandable for docs.

Docs are different in that they're often not mechanically checked and also timeless (or exist on a different timeline than the code, e.g. by also pointing out beta or deprecated features).

I don't think docs should timeless... how much developer time gets wasted because nobody can change docs of buggy code to warn people of the bugs?

I find this concept hard to explain Phrased differently: a code repository always contains a consistent, closed snapshot of some functionality. Docs often need to look behind or ahead.

Ok, so my point is, I think the same could be said of tests.

Anyway, for my final trick, (and @tpolecat might as well come back for this), we can all switch to source dependencies specified in terms of a selection of passing tests that we care about, and let a dependency manager find a coherent universe of dependencies for our project.