Jon Pretty

What do you mean by compatibility here?

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.