Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Releasing, Versioning and Deprecation #4

Closed
rainerleber opened this issue Dec 8, 2021 · 1 comment
Closed

Releasing, Versioning and Deprecation #4

rainerleber opened this issue Dec 8, 2021 · 1 comment
Assignees
Labels
documentation Improvements or additions to documentation pinned pinned issues

Comments

@rainerleber
Copy link
Collaborator

rainerleber commented Dec 8, 2021

Introduction
This issue describes how and when community.sap is released, and to announce updates to the release/versioning schedule. The next section (Next release) is always updated to contain the next version to be released. Most other changes to this first post are always announced by separate posts in this issue.

Next release
0.1.0 around December 12th
1.0.0 around February 18th

Releasing schedule for major and minor versions
2020-12-12: 0.1.0

From then on:

  • release minor versions every two months shortly before Ansible releases, i.e. roughly every three weeks

  • major versions every 6 months.

  • If no new commit has been merged for a minor release, it must be skipped. Major versions must not be skipped.

The schedule for minor versions might be adjusted in the future (maybe once per month, maybe something else). The release schedule for patch versions (see below) would be adjusted.

Releasing schedule for patch versions

  • Patch versions x.y.z until the last minor release of a major release branch will only be released when necessary. The intended frequency is never, they are reserved for packaging failures, or fixing major breakage / security problems.
  • Once the last minor release of a major release branch (usually x.2.0, generally x.Y.0) has been released, there will be bugfix releases x.Y.z.
  • These releases will happen every two months and when necessary.

Versioning

  • galaxy.yml in the main branch will always contain the version of the next major or 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 will eventually be enforced by CI.)

Branching

  • Releasing minor and major releases is done from stable-x branches.

  • Shortly (usually a few hours) before a new major release, stable-x is branched.

  • Once a new major version is released, there will be no more minor releases for previous stable-x branches.

  • From then on, only bugfixes are allowed for ~6 months

  • After that, only major bugfixes security fixes are allowed for another ~12 months (backporting to the current three major releases).

  • New features must not break backwards compatibility!

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 2 major versions (i.e. ~1 year). Maintainers can use a longer deprecation cycle if they want to support the old code for that long.

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!
    • (This might change later. The trivial category should then be used to document changes which are not important enough to end up in the text version of the changelog.)
    • 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.
  • The (x+1).0.0 changelog continues the x.0.0 changelog.

    • A x.y.0 changelog with y > 0 is not part of a changelog of a later X.. (with X > x) or x,Y,* (with Y > y) release.
    • A x.y.z changelog with z > 0 is not part of a changelog of a later (x+1).. or x.Y.z (with Y > y) release.
    • Since everything adding to the minor/patch changelogs are backports, the same changelog fragments of these minor/patch releases will be in the next major release's changelog. (This is the same behavior as in ansible/ansible.)
  • 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.

@rainerleber rainerleber self-assigned this Dec 8, 2021
@rainerleber rainerleber added documentation Improvements or additions to documentation pinned pinned issues labels Dec 8, 2021
@rainerleber rainerleber pinned this issue Dec 8, 2021
@rainerleber rainerleber unpinned this issue Dec 8, 2021
@rainerleber rainerleber pinned this issue Dec 8, 2021
@rainerleber
Copy link
Collaborator Author

migrated to new location

@rainerleber rainerleber unpinned this issue Aug 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation pinned pinned issues
Projects
None yet
Development

No branches or pull requests

1 participant