Is it broken, or not there yet?

Engine manuals and release notes are the fastest-rotting material there is. Six months in, half of it is wrong — APIs renamed, behaviour changed, things removed.

One thing doesn’t rot. When it appeared.

This isn’t trivia, it’s grounds for a verdict

The reason “added in 6.4” matters in QA is that when something won’t reproduce, that single line is what decides whether it’s a defect.

One symptom can mean two things.

• Something that should work doesn’t → a defect
• This version doesn’t have it yet → not a defect

You cannot tell them apart by looking. On screen they are both “it doesn’t work.” Logs don’t help either — a feature that isn’t there doesn’t throw, it just does nothing.

So when something won’t reproduce, suspect the version first. Skip that order and you end up filing a bug report against a feature that does not exist, which is the kind of false positive that costs a developer’s time.

The reverse holds too. When something was removed doesn’t rot either. Not knowing “removed in 5.8” means never finding out why something that worked fine has stopped.

The newest document does not supersede the old one

This is the counter-intuitive part. We assume the latest document is a superset of the older ones, and for date information it is the opposite.

Once a feature settles in, notes like “available from 6.4” quietly disappear from the documentation. A new reader doesn’t need them. So three years on, the docs read as though the feature was always there.

The only thing that still carries that marker is the release note from the time. Throw it away for being stale and it cannot be recovered.

Which means this class of material isn’t something you “update to the latest” — it’s something you accumulate. You go to the current manual for current behaviour and to the old release note for the date. The two documents do different jobs.

The honest limit

I am not yet running this as a ledger.

The links are collected, but I have never built the table that maps “the version our build uses” against “when each feature appeared.” Right now I look it up each time something fails to reproduce.

If the judgement in this piece is right, the next step is obvious — build that table, and write the version condition into the test case when it is authored. Recording it up front is cheaper than looking it up at verdict time.

I haven’t done it. So this is a judgement, not a report of work.