APE 20: Of black and backport

In APE 20, an implementation plan was laid out and the target was for v5.2. Since we are still on the hook to support v5.0.x as LTS until end of 2023 (see APE 2 and Release Calendar), there is the matter of how do we backport to v5.0.x branch in a sane way after this implementation for v5.2.

Some ideas:

• We also apply isort and black to v5.0.x branch to keep it in sync enough for the auto-backport bot to still work.
  • Concern: While the automation part should be relatively painless, any manual edit that has to go in risk actually breaking the code that we have promised would be “long-term stable.”
• We keep v5.0.x as-is but only limit manual backport to critical fixes in the event that auto-backport fails for any reason. See existing LTS policy at https://docs.astropy.org/en/latest/lts_policy.html .

This issue was a result of 2022-10-04 dev telecon discussions. cc @saimn @dhomeier @eerovaher @WilliamJamieson @braingram

Also cc @astropy/astropy-project-release-team

[mhvk]

Really this should be left to the black proponents to worry about, but I thought one nice thing about black at least is that it is guaranteed to not change the code, so no visual inspection would be necessary. This is a bit less true for isort, though any problems really should be caught by testing – and doing isort is less important since changes in the imports are less common(?).

I do think later in a LTS release cycle we can be a bit stricter about backporting and, as you suggest, when automatic backports fail, only do a manual one for critical fixes.

p.s. Of course the easier solution is to postpone the conversion till the next LTS…

[pllim]

This was decided upon and sent out as memos to mailing list.