Documented supported platforms with a support tier

[beorn7]

We would like to list the support of various platforms in the way it is done for etcd.

For example, the support for 32-bit architectures is currently a bit unclear. 386 on Linux is probably supported at tier 3 (using the etcd support tier definition). See also https://github.com/prometheus/prometheus/issues/16690 to improve the support.

[Dharma-09]

We can definitely build something similar to Rust’s platform support tiers. While that page goes into a lot of detail. we can start with a simpler version that lists supported platforms along with tier definitions (e.g., Tier 1: fully supported and tested, Tier 3: best-effort).

[ADITYATIWARI342005]

Hi @beorn7 Since there are no linked pull requests,

Can you please assign this to me.

I can implement this by:

Create a new file:

docs/supported-platforms.md || docs/operating/supported-platforms.md || op-guide/supported-platform/

• [ ] As you Instruct

Add a link:

1. In README.md under prerequisites or installation.
2. In the website navigation/sidebar.

Content to include:

1. Table of OS/arch combinations.
2. Support tier definitions.
3. Notes on 32-bit, ARM, Windows, etc.

[beorn7]

@ADITYATIWARI342005 thanks for your interest to help. Would this be your first contribution to Prometheus? It's probably not a good first issue to tackle as you need some familiarity with the Prometheus build pipeline and the test structure to do the necessary research to define meaningful support tiers and find out what tier is currently implemented for each platform.

Let me know if you still want to proceed here, and I'll assign you to the hissue.

[ADITYATIWARI342005]

@beorn7 It will indeed be my first contribution to Prometheus, and I'm currently gaining familiarity with Prometheus's architecture and build system with the goal of making meaningful contributions to the core project (prometheus/prometheus) for which I am currently referring the Docs . I understand this issue requires deeper knowledge of the build pipeline and test infrastructure, but I'm committed to learning what's necessary to deliver a quality contribution. I'd appreciate your guidance on:

1. Research approach: What's the best way to analyze the current build pipeline to understand which OS/arch combinations are actively tested vs. best-effort supported?
2. Support tier framework: Are there existing examples in other CNCF projects or industry standards I should reference for defining support tiers?
3. Testing infrastructure: Where should I look to understand the current test coverage across different platforms?

I'm willing to invest the time to understand these components properly rather than rush into implementation. And the fact that it will require learning, grows my interest. If you're open to mentoring, I'd be grateful for the learning opportunity and committed to seeing it through to completion. Please assign me to the issue if you're comfortable with this approach.

[beorn7]

These are good questions. The problem is that finding the answers to those questions is the meat of this issue. Or in other words: The mentor you will need to help you will probably do the majority share of work on this issue. That isn't a problem on its own, but we need a mentor that can invest this amount of time. (FTR: I'm hopelessly oversubscribed for months to come.)

If anyone can take the mentor role here, please say so.

@ADITYATIWARI342005 while you are waiting, I would propose to tackle more contained issues that do not require a huge amount of upfront work for others to get you up to speed.

[ADITYATIWARI342005]

@beorn7 Thank you for your honest and thoughtful response. I genuinely appreciate you explaining the scope and mentorship requirements - it gives me a much clearer understanding of what's involved.

I completely understand your limited availability and will follow your suggestion to start with more contained issues while building familiarity with the codebase and contribution process.

In parallel, I'll research and learn about the relevant topics for this issue and draft an initial version in two weeks. I hope you can review that when your schedule permits.

Thank you again for your guidance.