The published changelog is at trustivan.com/changelog. It is the record of what shipped, grouped by release, newest first. This page is the part that does not belong on a feed: what the entries mean, and what to read before you upgrade.

​
How an entry is grouped

Every entry carries a version, a date, and one or more labels: The labels exist so an operator can scan for breakage without reading prose. If an entry has neither changed, security nor deprecated, upgrading to it does not require you to change anything. A change that alters behaviour for an existing deployment is called out in the entry rather than left to be inferred from a feature description. A changelog that buries the migration note under the announcement is a changelog people stop reading.

​
Before you upgrade

  1. Read every entry between your version and the target, not just the newest — changed and security labels are what you are looking for.
  2. Check whether the release adds migrations. If it does, they must be applied before the new binaries start; see migrate and Upgrades.
  3. Check the versioning rules for what is guaranteed not to have broken.

​
What is not in the changelog

The changelog records product changes. It is not:
  • A security advisory feed. A fixed vulnerability appears here labelled security, but coordinated disclosure and the reporting process are covered in Reporting a vulnerability.
  • The upstream scanner’s changelog. TRUSTIVAN’s releases and the vendored scanning engine’s releases are different things on different schedules. When a release changes the engine version, the entry says so; the engine’s own notes are the upstream project’s, and Upstream and attribution explains the boundary.
  • A vulnerability database feed. Advisory data updates continuously and independently of releases. That is the point of it — a scan’s freshness is reported per scan, not per release. See Vulnerability database.