doc/src/backport_policy: init

[trueNAHO]

Initialize a backport policy to avoid ambiguity and reduce maintenance
efforts.

Adding the backport policy was first mentioned in #2116 (review).

Here is the output of nix run .#doc:

---

• I certify that I have the right to submit this contribution under the MIT license
• Commit messages adhere to Stylix commit conventions
• Theming changes adhere to the Stylix style guide
• Changes have been tested locally
• Changes have been tested in testbeds
• Each commit in this PR is suitable for backport to the current stable branch
  • Let's backport this for good measure, although it goes against the proposed backport policy.

[0xda157]

the fact that ci changes should always be backported should be mentioned here. also we should decide on backporting document changes, recently we have been but i'm neutral on the matter.

[danth]

I think we should backport documentation because it improves usability. No code changes means it can't break existing configurations, so the branch is still stable. Of course, it's important to make sure that the features being documented do actually exist in the older version.

[trueNAHO]

the fact that ci changes should always be backported should be mentioned here.

Good catch! I forgot to mention this.

also we should decide on backporting document changes, recently we have been but i'm neutral on the matter.

I think we should backport documentation because it improves usability. No code changes means it can't break existing configurations, so the branch is still stable. Of course, it's important to make sure that the features being documented do actually exist in the older version.

I am rather neutral about documentation backports, but what value would it provide besides potential LSP documentation improvements? Since the stable tree is already out-of-sync with the stable behavior, it seems unreliable to expect the /doc/ documentation to be accurately reflective.

Should documentation backports not only be restricted to pure documentation changes without behavior changes? Without manually cherry-picked backports, which this policy aims to reduce, the number of pure documentation changes (commits) to Nix options for the LSP seems fairly low.

[danth]

This paragraph conflicts with a previous statement:

To reduce maintenance efforts and improve stability on stable branches [...] new features, modules, and theme
improvements are not backported.

The expectation of a stable branch is generally that it only receives fixes to the existing feature set, as described above.

I'd suggest either changing our policy to fit that expectation, or explaining why this exception is appropriate.

[trueNAHO]

This paragraph conflicts with a previous statement:

To reduce maintenance efforts and improve stability on stable branches [...] new features, modules, and theme
improvements are not backported.

The expectation of a stable branch is generally that it only receives fixes to the existing feature set, as described above.

That's the point. This is an additional constraint that acts as an exception to the previously mentioned default constraints. This is motivated by the fact that stable users commenting on unstable PRs for them to be backported happens more often than expected.

I'd suggest either changing our policy to fit that expectation, or explaining why this exception is appropriate.

Should we not keep the policy document concise and purely about the procedure without explaining its reasoning and motivation in great detail? The reasoning is already alluded with "when explicitly requested", and this exception seems justifiable unless the "backporting is trivial" condition does not hold.

[0xda157]

this should be more general. #2237 is good example of this.

Suggested change

	and theme improvements are not backported. Upstream changes rendering themes
	unreadable are considered a bug.
	and theme improvements are not backported. Upstream changes causing theming
	issues are considered a bug.