Releasing, Versioning and Deprecation

[ispim]

Introduction
This issue describes how and when isnpur.sm 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. Other changes to this first post are always announced by separate posts in this issue.

Next release

2.0.0 probably of May 2023

1.1.0 probably of Aug 2022

Releasing schedule for major and minor versions

2022-05-17: 1.0.0 major release

From the 1.0.0:

release minor versions every three months.

release major versions every years.

The precise dates will be announced on time.

2022-08-xx: 1.1.0

2022-11-xx: 1.2.0

2023-02-xx: 1.3.0

2023-05-xx: 2.0.0 major release

2024-05-xx: 3.0.0 major release

2025-05-xx: 4.0.0 major release

…

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 threemonths and when necessary.

Versioning

galaxy.yml in the master 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.

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 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.

o Exception: fixing/extending a feature that already has a changelog fragment and has not yet been released. Such PRs mustalways link to the original PR(s) they update.
o Use your common sense!
o (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.)
o 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.