Amvionlie CMS
Where the Future Begins

Changelog Entry Rules

Use this page when deciding whether a change needs a Changelog record and what that record should contain.

Current Table

The active Changelog admin panel reads:

amv_changelog_entries

Do not write new records to `amv_system_manager_changelog`; that is the old table.

Rule

Every meaningful governed change should produce a clear Changelog entry.

This includes:

  • code changes
  • Wiki/documentation changes
  • schema changes
  • admin workflow changes
  • installer/system governance lifecycle behavior
  • permission changes
  • security changes
  • package/sample changes

Required Columns

A useful DB entry includes:

  • `entry_sequence`
  • `version_uuid`
  • `version_label`
  • `version_sort_value`
  • `lifecycle_key`
  • `release_state`
  • `change_type`
  • `title_text`
  • `summary_text`
  • `impact_text`
  • `area_key`
  • `release_label`
  • `source_key`
  • `actor_label`
  • `created_at`
  • `updated_at`

Use the current `unreleased` version row unless the change belongs to a specific release.

Change Types

Use lowercase values in DB:

  • `added`
  • `changed`
  • `fixed`
  • `removed`
  • `deprecated`
  • `security`

Example Entry Meaning

Title:

Expanded Wiki addon developer guide

Summary:

Synced corrected manifest samples into the live Wiki and expanded addon manifest, install contract, build walkthrough, admin workflow, Menu Manager target, hooks/events, and system governance/Installer responsibility guidance.

Impact:

Third-party developers now have a more complete buildable path for creating, packaging, installing, updating, and administering a simple governed addon.

Writing Rules

  • Keep titles short and specific.
  • Summaries say what changed.
  • Impact says why it matters.
  • Avoid raw UUID dumps in the user-facing text.
  • Use `area_key` values such as `wiki`, `docs`, `installer`, `system governance`, `permissions`, or the addon key.
  • Do not create duplicate records for the same completed change.

Root Changelog

When scope allows, update root `CHANGELOG.md` too. If root changelog does not exist, create it with an `Unreleased` section.

Related: Installer/Package Install and Update Flow, Permissions/Permission Manifest Declarations.

Updated: 2026-05-07 02:18:09