Skip to content

Latest commit

 

History

History
46 lines (40 loc) · 2.72 KB

RELEASE.md

File metadata and controls

46 lines (40 loc) · 2.72 KB

Release cycle and versioning

Versioning

Versioning is using SemVer (X.Y.Z):

  • The X is a major version and is incremented when:

    • Support for older Zabbix versions is removed.
    • Support for older Ansible versions is removed.
    • Support for older Python versions is removed.
    • Modules, roles or plugins are removed.
    • Module or role functionality is removed.
    • Other breaking changes or backward-incompatible changes are introduced.
  • The Y is a minor version and is incremented when:

    • Support for new Zabbix versions is added.
    • Support for new Ansible versions is added.
    • Support for new Python versions is added.
    • A new module, role, plugin, etc., is added.
    • New features are introduced to modules, roles, plugins.
    • A functionality of components is adjusted in a backward-compatible way.
  • The Z is a patch version and is incremented when:

    • Bugs are fixed in a backward-compatible way.
    • Documentation fixes and smaller changes are introduced.

Releases

Release dates are not fixed. Instead, they will be discussed at the beginning of each month following this guideline:

  • The version increment will depend on the content that will be included in the release, as discussed in the Versioning section.
  • New collection releases may be a result of this discussion if necessary.
  • There may be several releases during the month if needed.

Collection support

The latest release of the community.zabbix is always supported. Older releases, which are included in the still supported Ansible versions, may obtain occasional backports or bug fixes when necessary. [1]

[1] Collection versioning requirements

Branches

Branch main always holds the code for the latest supported release. New branch stable-X.Y is pushed before starting a new major (X+1) version development in the main branch.

The stable-X.Y branch provides a way to merge any necessary backports and release bug fixes for older major versions of this collection while they are still included in currently supported ansible releases.

For example, if the current version of the collection is 1.3.2 and a new version 2.0.0 is being released, the branch stable-1.Y should be pushed prior to the release, matching the last commit that was included with the 1.3.2 release.

Merging

Merging follows this guideline:

  • Main branch (previously master branch) is the current branch.
  • stable-X.Y is a separate branch used to fix issues in older supported collection releases.
  • There should be a separate branch for each contribution.
  • There should be a separate pull request for each version increment.