Description
The context
Static validation: Pester tests aim to ensure each module leverages an API version which is "recent enough", not older than the latest e.g. X released versions.
Module readme: documentation aims to ensure each used API version is tracked and linked to the official corresponding documentation in the Azure Resource Reference.
The problem
The Azure Resource Reference is often not up-to-date and sometimes completely lacking documentation for certain resource types.
When checking the right API version to choose for a resource type, we often fall into the discussion of which latest version we should consider: if the latest stable released or if the latest documented by the Azure Resource Reference. See for instance discussion in PR #1662
In general, we must avoid providing a wrong documentation, i.e. linking a documentation from the Azure Resource Reference which is not corresponding to the one used by the modules. This is currently the case for some resources.
Acceptance criteria
This issue is about
- discussing and agreeing on the criteria to follow when updating an API version/implementing a new module
- documenting the decision in the wiki
- the decision may impact either the Pester tests logic or the readme API version documentation to provide, for which separated issues will be opened.
Description
The context
Static validation: Pester tests aim to ensure each module leverages an API version which is "recent enough", not older than the latest e.g. X released versions.
Module readme: documentation aims to ensure each used API version is tracked and linked to the official corresponding documentation in the Azure Resource Reference.
The problem
The Azure Resource Reference is often not up-to-date and sometimes completely lacking documentation for certain resource types.
When checking the right API version to choose for a resource type, we often fall into the discussion of which latest version we should consider: if the latest stable released or if the latest documented by the Azure Resource Reference. See for instance discussion in PR #1662
In general, we must avoid providing a wrong documentation, i.e. linking a documentation from the Azure Resource Reference which is not corresponding to the one used by the modules. This is currently the case for some resources.
Acceptance criteria
This issue is about