Bicep Utility Module Specifications
# | ID | Title | Severity | Persona | Lifecycle |
---|---|---|---|---|---|
1 | BCPNFR14 | Versioning |
See Specifications for this chapter
To meet
SNFR17
and depending on the changes you make, you may need to bump the version in the version.json
file.
{
"$schema": "https://aka.ms/bicep-registry-module-version-file-schema#",
"version": "0.1",
"pathFilters": [
"./main.json"
]
}
The version
value is in the form of MAJOR.MINOR
. The PATCH version will be incremented by the CI automatically when publishing the module to the Public Bicep Registry once the corresponding pull request is merged. Therefore, contributions that would only require an update of the patch version, can keep the version.json
file intact.
For example, the version
value should be:
0.1
for new modules, so that they can be released asv0.1.0
.1.0
once the module owner signs off the module is stable enough for itโs first Major release ofv1.0.0
.0.x
for all feature updates between the first releasev0.1.0
and the first Major release ofv1.0.0
.
# | ID | Title | Severity | Persona | Lifecycle |
---|---|---|---|---|---|
1 | SNFR17 | Semantic Versioning |
See Specifications for this chapter
You cannot specify the patch version for Bicep modules in the public Bicep Registry, as this is automatically incremented by 1 each time a module is published. You can only set the Major and Minor versions.
See the Bicep Contribution Guide for more information.
Modules MUST use semantic versioning (aka semver) for their versions and releases in accordance with: Semantic Versioning 2.0.0
For example all modules should be released using a semantic version that matches this pattern: X.Y.Z
X
== Major VersionY
== Minor VersionZ
== Patch Version
Initially modules MUST be released as version
0.1.0
and incremented via Minor and Patch versions only until the AVM Core Team are confident the AVM specifications are mature enough and appropriate CI test coverage is in place, plus the module owner is happy the module has been “road tested” and is now stable enough for its first Major release of version1.0.0
.Releasing as version0.1.0
initially and only incrementing Minor and Patch versions allows the module owner to make breaking changes more easily and frequently as it’s still not an official Major/Stable release. ๐Until first Major version
1.0.0
is released, given a version numberX.Y.Z
:X
Major version MUST NOT be bumped.Y
Minor version MUST be bumped when introducing breaking changes (which would normally bump Major after1.0.0
release) or feature updates (same as it will be after1.0.0
release).Z
Patch version MUST be bumped when introducing non-breaking, backward compatible bug fixes (same as it will be after1.0.0
release).