[C++] Define an official support policy

[pitrou]

Describe the enhancement requested

For now, our "support" policy has been taking an opportunistic/slippery-slope approach: someone adds a platform/CI build in a PR, and then maintainers are collectively expected to keep the corresponding build green.

The problem is this creates a growing maintenance hurdle as more and more configurations are tested on CI and supposed to remain green. For example, we have been adding builds for Meson, Emscripten, etc.

We should be more rigorous in defining our support levels and what the expectations are towards maintainers and release managers.

We could for example take some inspiration from Python, which defines three support levels:

• tier 1 platforms: tested on CI, should remain green as much as possible, release-blocking
• tier 2 platforms: tested on CI, best effort, don't block a release
• tier 3 platforms: all the rest, unsupported though we might want to accept patches for them, depending on the perceived maintenance overhead

The corresponding Python spec is more detailed and lists the concrete platforms for each tier: https://peps.python.org/pep-0011/

Though this ticket tracks the enhancement, this should certainly be discussed on the dev list to reach more people.

Component(s)

C++, Continuous Integration, Release

[pitrou]

cc @kou @raulcd @assignUser @zanmato1984 @kszucs @amoeba @WillAyd

[pitrou]

(once C++ is tackled, we may want to do this for PyArrow too)

[assignUser]

+100

I have brought this up in the community meetings years ago but never got around formulating a draft for a support policy.

I think a well formulated policy creates clarity for both users and us devs. We should have this for all implementations eventually, for some the language implies it already (like go) or it has already been discussed (rust).

[WillAyd]

I agree adopting the CPython tier approach would be really nice here, and should work in a mutually beneficial way.

[amoeba]

+1, I think three tiers is a good structure. I'll add that I also really like how Python keeps a removal history under No-longer-supported Platforms.

[kou]

+1

Can we define the followings too?

• How to change the tier for platform X (e.g.: tier 2 -> tier 1, tier 2 -> tier 2, ...)
  • FYI: We have https://arrow.apache.org/docs/format/Changing.html for format specification change
• How to classify tier 1 CI and other tiers' CI
  • If we use "just ignore tier 2 CI failures" approach, I feel that it's costly. Because maintainers need to check whether the CI failure is ignoreable or not manually before they merge.

[zanmato1984]

+1

I only experienced a few times of tricky platform-specific problems in some of my PRs, but personally I think the current extent of the supported platforms might be too much, not mentioning that the trend is only increasing. So I'd put a strong +1 on this proposal. And the proposed tiered support plan looks quite reasonable and nice!

[raulcd]

+1

If we use "just ignore tier 2 CI failures" approach, I feel that it's costly.

Tier 1 should probably be run as part of main CI. Tier 2 should be part of "extra CI" (crossbow) not main and probably be identified as such, we could have groups of crossbow tasks for identifying different tiers.

[assignUser]

As part of this we could also document which versions of Arrow we support as we don't have that written down anywhere I think? Currently we implicitly only support the current major version, with very rarely backports/workarounds for older versions.

[ianmcook]

+1, but with an important caveat:

We should give stakeholders an opportunity to contribute resources toward keeping support for environments that we would otherwise drop support for. We should broadcast plans to drop support sufficiently prominently and sufficiently early to allow stakeholders to take notice and offer resources.

A good example of this being done well is the discussion about deprecating support for CentOS 7. There was a proposal to drop support for it in #41395 but Voltron Data offered to contribute resources to maintain support for it.

In some cases, a compelling rationale might suffice in lieu of resources, but a demand without a compelling rationale or an offer of resources should not suffice.