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