Description
Introduction
This issue describes how and when netapp collections are released, and to announce updates to the release/versioning schedule. Other changes to this first post are always announced by separate posts in this issue.
Versioning schema
Until April 2021, releases are numbered as YY.M.P or YY.MM.P.
- YY is the year, eg 21 for 2021
- M or MM is the month, 1 to 12 (leading 0 is not allowed) - for simplification, we will use MM below.
- P is the patch number. A 0 indicates the first minor release of the month, P > 0 indicates a patch release.
Starting in April, we are switching to semantic versioning as M.m.p
- M is the major version, currently 21.
- m is the minor version, currently 4.
- p is the patch number, with a value of 0 for the initial release.
You can see that for 2021, the two versioning schemas overlap.
But we already released 21.5.0 as of April 22, and 21.6.0 as of May 06.
Releasing schedule for major and minor versions
Our intent is to release collection updates on the first Wednesday of every month.
The collections that are active as of April 2021 are CloudManager and ONTAP, and are most likely to see regular updates. Other collections will only be updated if a feature request or a non urgent bug fix is ready for this month.
If no new commit has been merged for a minor release, it must be skipped.
We strive to maintain backwards compatibility. If there is a strong enough justification, we will increase the Major release number to indicate a chance of a breaking change.
Releasing schedule for patch versions
If possible, we will wait for the next minor release. If we deem the fix urgent, we will release a patch version as MM.m.p with z > 0.
Versioning
galaxy.yml in the master branch will always contain the version of the next minor release. It will be updated right after a release.
version_added needs to be used for every new feature and module/plugin, and needs to coincide with the next minor/major release version. (This is enforced by our internal CI.)
Branching
Releasing major or minor releases is done from a tagged master branch.
New features must not break backwards compatibility. If there is a strong enough justification, we will increase the Major release number to indicate a chance of a breaking change.
Backporting process
We do not backport any change. As new versions maintain backward compatibility, it is always possible to move to a new minor version. If we introduce a major change, we may revisit this statement.
Deprecation
Deprecations are done by version number (not by date).
New deprecations can be added during every minor release, under the condition that they do not break backwards compatibility.
Deprecations are expected to have a deprecation cycle of at least 1 year.
Changelogs
Every change that does not only affect docs or tests must have a changelog fragment.
Exception: fixing/extending a feature that already has a changelog fragment and has not yet been released. Such PRs must always link to the original PR(s) they update.
Use your common sense!
Fragments must not be added for new module PRs and new plugin PRs. The only exception are test and filter plugins: these are not automatically documented yet.
Changelogs do not contain previous major releases, and only use the ancestor feature (in changelogs/changelog.yaml) to point to the previous major release.
Changelog fragments are removed after a release is made.