Changelog: the page that carries dates

A changelog is a dated record of changes. In this field its presence is close to a proxy for whether a vendor can be planned around: changelogs and developer documentation carry dates, while marketing pages carry adjectives, and most of the entries here have only the second. As of 2026-09-22.

Inclusion rule. Distinctions drawn from the pages used as sources in this register: lifecycle pages, deprecations pages and priced product pages. Order. What each kind of page carries, most useful first.

1Dates are the whole product

A vendor with a dated changelog is giving a production something to plan against even when the news is bad. A vendor without one can be entirely reliable and still impossible to schedule around.

This register only records dates a vendor published, so an entry with no changelog contributes only a menu reading. That is a limitation of the source material rather than a judgement.

2Follow the model upstream

For a model reached through an application, the application's pages are usually silent and the maker's are not. The useful habit is to follow the model name to whoever makes it rather than waiting for the reseller to mention anything.

That works only if the reseller named a version. Where it named a maker, the upstream page cannot be matched to the purchase.

3Two readings of a page is the substitute

Where no changelog exists, the only evidence of change is the same page read at two different times. That is what the dataset here is for, and it is why every row carries the date it was read.

It detects change after the fact and never predicts it. The data page explains why the file is more useful as a series than as a snapshot.

A definition rather than a dated entry: no line above is a vendor statement. Where this word turns up in a real notice, the wording and the date are on how entries here are dated. Nearby terms: Successor model, Silent update, Endpoint.