BCPNRF22 - Bicep Module Changelog
ID: BCPNRF22 - Category: Publishing - Changelog
When a module to be published (i.e., that has a version.json
file) is changed, an entry MUST be created in the CHANGELOG.md
file in the module folder.
Note
The versioning is following the SNFR17 - Semantic Versioning spec.
For each new version, an entry MUST be created above all existing versions in the CHANGELOG.md
file of the module.
## <version>
### Changes
- this changed
- and this also
### Breaking Changes
- none
Each version’s entry MUST contain two sections: Changes and Breaking Changes. At least one of them must have a meaningful entry and sections must not be left empty. A - none
may be added as content for a section.
Example content of the CHANGELOG.md
A CHANGELOG.md
file in the module’s root folder MUST start with the # Changelog
header, followed by an empty line. A section for each published version follows. Newer versions are placed above older versions.
# Changelog
## 0.2.1
### Changes
- Updated the referenced AVM common types
### Breaking Changes
- none
## 0.2.0
### Changes
- Implemented the minCPU parameter
- Updated the referenced VirtualNetwork module
- Updated the referenced AVM common types
### Breaking Changes
- The minCPU parameter is mandatory
## 0.1.0
### Changes
- Initial Release
### Breaking Changes
- none
Manual Editing
It is possible to modify the changelog content any time, e.g., to add missing versions. Please note the following requirements in all cases:
- all versions in the file, need to be valid and available as published version
- every version needs the two sections
## Changes
and## Breaking Changes
with content
Note
Azure Verified Modules are artifacts in the Microsoft Container Registry (MCR). Every version of a module exists as a tag in the Container Registry and can be listed as tags for each module https://mcr.microsoft.com/v2/bicep/avm/(res|ptn|utl)/<namespace/modulename>/tags/list