Changelogs and Updates
When you publish your plugin in the Plugin Store, you will be able to specify a path to your plugin’s changelog within the repository.
If this is set to a valid changelog path, the Plugin Store will re-download your changelog on each release. Those release notes will then be displayed for your plugin on the page at Utilities → Updates.
# Setting Up a Changelog
CHANGELOG.md file at the root of your plugin’s repo, where you can start documenting release notes for your plugin. Use something like this as a starting point:
# Release Notes for <Plugin Name>
Within the changelog, releases must be listed in descending order (newest-to-oldest). (When displaying available plugin updates, the Plugin Store will stop parsing a plugin’s changelog as soon as it finds a version that is older than or equal to the user’s installed version.)
# Version Headings
Version headings in your changelog must follow this format:
## X.Y.Z - YYYY-MM-DD
There’s a little wiggle room on that:
- Other text can come before the version number, like the plugin’s name.
- A 4th version number is allowed (e.g.
- Prerelease versions are allowed (e.g.
- The version can start with
- The version can be hyperlinked (e.g.
- Dates can use dots as separators, rather than hyphens (e.g.
Any H2s that don’t follow this format will be ignored, including any content that follows them leading up to the next H2.
# Release Notes
All content that follows a version heading (up to the next H2) will be treated as the release notes for the update.
When writing release notes, we recommend that you follow the guidelines at keepachangelog.com (opens new window), but all forms of GitHub Flavored Markdown (opens new window) are allowed. The only thing that is not allowed is actual HTML code, which will be escaped.
# Notes, Warnings, and Tips
You can include important notes, warnings, and tips in your release notes using this syntax:
> **Note** > An important note. > **Warning** > A word of warning. > **Tip** > A helpful tip.
These notes will each be styled appropriately within the plugin’s changelog in the Plugin Store and within the Updates utility. The Updates utility will also auto-expand any updates that contain a note.
If you have any reference-style links in your release notes, you will need to define the URLs before the following version heading:
## 2.0.1 - 2017-02-01 ### Fixed issue [#123] [#123]: https://github.com/pixelandtonic/foo/issues/123 ## 2.0.0 - 2017-01-31 ### Added - New [superFoo] config setting [superFoo]: https://docs.my-plugin.tld/config#superFoo
# Critical Updates
If an update contains a fix for a critical security vulnerability or other dangerous bug, you can alert your users about it by adding
[CRITICAL] to the end of the version heading:
## 2.0.1 - 2017-01-21 [CRITICAL] ### Fixed - Reverted change to `$potus` due to security vulnerabilities
When Craft finds out that a critical update is available, it will post a message about it to the top of all control panel pages, and give the update special attention on the Utilities → Updates page.