Reading platform comparison updates: six triggers and when to retire

A comparison is the most perishable thing a catalog publishes. A directory entry describes one service and goes stale one field at a time. A comparison describes a relationship between two, so it goes stale when either end moves, and it goes actively wrong when they move in opposite directions.

Rechecking all of them constantly is not possible for anyone. What is possible is a small set of triggers that say when a specific comparison needs looking at, and an honest rule for when a comparison should be retired instead of updated. That is what this page sets out.

What to take away

Why a calendar does not work here

Say a catalog has thirty comparisons across twenty services. Rechecking each quarterly means 120 full re-tests a year, each with matched accounts and a fixed window. Nobody does that.

So the dates get updated and the tests do not. That is worse than an obviously old page, because it looks maintained.

Triggers invert the problem. Watch the twenty services, which you are doing anyway for their own entries, and let events on them decide which of the thirty comparisons needs work. In a normal quarter that is two or three, which is a job somebody can actually do.

The six triggers

A pricing change on either service. The commonest trigger and the one most likely to flip a conclusion, because price is where a reader's requirement usually binds.

A tier restructure. More consequential than a price move and much less announced. A capability crossing from a free tier to a paid one changes what a comparison of the free tiers was even about.

An ownership change. Resets confidence in everything about that service, and therefore in every comparison it appears in. Mark them all for recheck rather than trying to guess which fields moved.

A change in distribution behavior. Where one of the axes is about who decides that a post is seen, an announced or observed change there invalidates the row directly. It is also the hardest to detect, since much of it arrives as a staged rollout rather than an announcement, in the way the notes on watching a large service change describe.

A change to export or import. The rows about leaving are the ones readers rely on most, and they move quietly.

A deprecation. When either service withdraws a capability the comparison depended on, the row is not merely stale, it is describing something that no longer exists. Following the deprecation notices in developer documentation is the cheapest early warning available, because deprecations are announced with lead time when nothing else is.

Detecting the triggers without a full watch

Most of the detection is already happening if the individual service entries are on a watch list. The comparison layer adds one thing: a map from each service to the comparisons it appears in, so that a logged change on a service automatically raises the affected comparisons.

That map is a two-column table and it is the only new maintenance object this page asks for. Without it, someone has to remember which comparisons mention which service, and after a year nobody does.

Beyond that, subscribe to whatever release feed each service publishes. A project that publishes its release life cycle tells you in advance which of the six triggers is about to fire.

The general watch-list method and the three-bin triage of what a diff turns up are in the notes on watching a community platform, and they work unchanged here.

What a recheck actually involves

Not a full re-run. A trigger names a row, and the recheck is scoped to that row plus anything the row depends on.

Keeping partial re-tests separate from full cycles matters for the series, because a series needs points produced the same way. The discipline for repeating a comparison as a series covers why mixing the two ends a series without anyone noticing.

When to retire instead of update

Four cases, and in all of them patching is the wrong move.

One service has closed. Archive with dates. The page becomes history and should say so in the first line.

The two are no longer alternatives. One has changed enough that no reader could substitute it for the other. Archive it and point at the substitution sets each now belongs to.

The premise was wrong. Sometimes a comparison was built on a pairing that never should have existed. Retire it and say why, rather than quietly improving it.

Nobody can test it any more. A capability moved behind a tier the catalog cannot access. Retire the row, or the page, rather than filling it from documentation and calling it tested.

An archived comparison keeps its URL and gains a dated banner. It should never simply vanish, because people have linked to it and because the record of what was true is itself useful.

What a page dated to a year can promise here

It can promise the method, the trigger list, the date of the last full cycle, and the date of the last partial re-test per row. It can promise that a retired comparison is marked rather than deleted.

It cannot promise that the conclusion still holds. A comparison is exactly the kind of page a reader will assume is current because it looks like a decision. Say plainly, near the top, what was tested and when, and that any conclusion is a conclusion about that moment.

The axes underneath change slowly, which is the argument for building on them at all, as the six-axis method sets out; the rows built from testing change fast, and only the dates tell a reader which is which.

Common questions

How long until a comparison is not worth reading?

Depends entirely on which rows are doing the work. A comparison decided by a structural axis stays useful for years. One decided by pricing or by a feature gate is out of date within months, and it should say which kind it is.

Should the page show its own change history?

A short one, in plain language: what changed, when, and whether the conclusion moved. Readers who bookmarked it need to know whether to reread. The evidence sits behind it for anyone who wants it.

What if a service changes while a test is running?

Abandon the run and start it again, with a note of what happened. A run that straddles a change is a measurement of neither state, and the temptation to keep it because it took a week is exactly how a series gets quietly poisoned.

Is there ever a reason to update a retired comparison?

Only to correct a factual error in what it recorded. Bringing it back requires a fresh full run under the current method, at which point it is a new comparison with a new date and the old one stays in the archive.