[policy, no patch] Clarify the policy around backporting changes with potential issues

Just dumping some things to think about too....

• hook_update_N minimise them in patch versions?
• post updates minimise too?
• String changes / additions?
• Bugs vs tasks
• Experimental
• Test system - allow additions but not change?

Mark underscored things @internal in the backport patch and add a note that they'll be removed is another unwritten rule.

Strings a big part of it is whether they're visitor/content editor/admin/developer facing.

Many of these rules are written in various places, e.g.:
https://www.drupal.org/core/d8-bc-policy#underscore
https://www.drupal.org/core/experimental
https://www.drupal.org/core/d8-allowed-changes#patch

Strings are covered in:
https://www.drupal.org/core/d8-bc-policy#strings

The D7 policy has more specific (probably too much) detail:
https://www.drupal.org/node/1527558
https://www.drupal.org/core/d8-allowed-changes#patch
https://www.drupal.org/core/d8-allowed-changes#minor

So it would be good to know what the goal of this issue is, e.g., whether it's to add an explicit how-to for backporting etc. OTOH we also adopted the policy that we default to committing borderline things to the dev minor only and only backport things that are easy/safe or high priority. So I can also see a case for not adding a whole section about how to backport things when we want it to be the exception rather than the rule for things that are not major/critical bugs etc.

@xjm I think Daniel opened it for a 'howto for backporting'. If we did add a section we could say it's only for major/critical bugs.

Updates are more problematic than that, per #2743297-8: Mis-named update function in views.

We add views_update_8102() for issue 123456 - this is added to 8.2.x then backported to 8.1.x

Then we add views_update_8200() for issue 654321 - this is added to 8.2.x, then never gets backported.

Then we add views_update_8103() for issue 321654, this is added to 8.2.x then backported to 8.1.x

If you are running 8.2.x-dev (or if we're in beta/rc), then views_update_8103() will never run on your site, because your schema version is 8203(), despite being in both branches and with no conflict between patches.

So within the constraints of the current update system, we'd have to have views_update_8103() set a state entry like views_update_8103_has_run, then in views_update_8203() we check that state entry, and if it's not there make the same changes again (otherwise it could run twice instead of never, which can have its own problems).

This is both hard to explain, and also hard to spot when it happens, so just not backporting hook_update_N() unless it's a very, very critical issue would be best. Of course we could also add centralised docs explaining why it's such a bad idea and hard to do properly.

Adding to my policy review list.

I think @xjm's sentence here still describes the status quo several years later

OTOH we also adopted the policy that we default to committing borderline things to the dev minor only and only backport things that are easy/safe or high priority.

I still see quite a few cases where people ask why x somewhat tricky bugfix hasn't been backported, was going to say we should add a note about it to https://www.drupal.org/about/core/policies/core-change-policies/allowed-..., but it's already on there. We should probably update that issue for the 'main' branch though now we're always targeting issues at that branch and moving the issue to an older branch only if we commit the backport there.

I agree the docs need updating and have made a note on #3294814: [Policy] Branch Naming: Use an 11.x branch for HEAD, then use 'main' when d.o can support it as well as adding to my to do list.

Since current practice is documented and the policies have been updated since 2016 I am closing this as outdated.

Changing to latest version when this was closed.

Crediting discussion participants.