Purpose

Every Academy article carries three date/version fields. This document defines what each field means and who is responsible for updating it.

The three fields

FieldFormatMeaning
version 1.0, 1.1, 2.0 The article's own content version. Increment the minor version (1.0 → 1.1) for corrections, clarifications, or added content. Increment the major version (1.x → 2.0) when the underlying feature has changed substantially enough that the previous version would actively mislead a reader.
last_reviewed YYYY-MM-DD The date the article was last reviewed for accuracy, even if no content changed. Update this every time a review confirms the article is still accurate. This prevents articles that happen to be correct from appearing stale.
stale_after YYYY-MM-DD The date after which the article should be reviewed. Set to 90 days after last_reviewed for most articles. Set to 30 days for articles covering integrations (Paystack, Termii, WhatsApp) that are more likely to change. Set to 180 days for conceptual or definitional articles unlikely to change.

Stale-after calculation

When updating last_reviewed, always set stale_after at the same time:

  • Standard article: stale_after = last_reviewed + 90 days
  • Integration article (payment, SMS, WhatsApp): stale_after = last_reviewed + 30 days
  • Conceptual/definitional article: stale_after = last_reviewed + 180 days

The sv_is_stale() function in /includes/functions.php compares today's date to stale_after and shows the amber "may be outdated" banner if the date has passed.

sv_release field

The optional sv_release field records the School Vault platform version at which the described feature became available. Format: 1.0.0. Use this when an article documents a feature that was added in a specific release, so readers on older deployments know whether the feature applies to them.

Version bump checklist

Before saving any article change:

  1. Update last_reviewed to today's date.
  2. Recalculate and update stale_after.
  3. If content changed: increment version (minor for corrections, major for substantial rewrites).
  4. Add a changelog entry describing what changed and why.