Minimal proposal

• Provide a release of Clutter that gets maintained for more than one cycle and that can be used for inclusion in long term support distributions, or targeted for minimal dependency.

Rationale

Currently, each development cycle of Clutter will result in two things happening every six months:

• a new stable release
• an old stable release

The new stable release will see at least two more point releases, to fit into the GNOME development cycle. The old stable release, instead, is discontinued, and it is not updated any more.

The current releasing process favours rapid development cycles, with new API added (and deprecated) with a fairly short turnover. Once a stable release becomes old-stable, though, it is pretty much abandoned, and no bug fixes are backported or applied, except by distributions.

Some distributions provide long term support releases which keep shipping the same version of the Clutter package - whichever stable version happens to be released at the time. This means that all bug fixes end up either inside distribution packages or unreleased in Git.

Implementation

• The development cycle remains six months in duration, and a new stable release is cut at the end of each cycle.

• Every third cycle, the stable release is declared a Long Term Support release.

  • The duration of support is, thus, 18 months.

  • Example: 2.0 → 2.2 → 2.4 (LTS) → 2.6

• Patches that do not depend on new API are backported from the current development branch to the LTS branch, once they have been proved to not introduce regressions.
  • Backporting depends on passing the conformance test suite of the LTS branch, as well as QA on a well-defined set of Clutter applications and libraries.
• Releases from the LTS branch are done at least once every development cycle.
• Backports to LTS are tracked on Bugzilla only, and discussed with various stakeholders (packagers, maintainers of the well-defined set of Clutter users).

Issues/Discussion

• Q: What happens if we need to introduce new API to fix an issue?

  • A: We cannot bump the soname, so it'd need to be private API, which means a non-trivial cherry-pick.

• Q: What happens if we need to bump a dependency to fix an issue?

  • A: We may depend on libraries that do not follow LTS rules, so we cannot really bump a dependency without fallout.

• Q: Is 2.0 going to be a LTS?

  • A: No, given that the API will most likely need time to settle for the following cycle at the very least.