idea: Introducing Component Support Tiers for OpenDAL

[Xuanwo]

OpenDAL has grown to include many components—storage back-ends, middleware layers, language bindings, and more.
Borrowing from Rust’s target tiers, we propose a lightweight support matrix so users can gauge risk and maintainers can focus effort.

---

The Three Tiers

Tier	Maintainer Coverage	Known Users	CI / Release Rules	Deprecation Policy
1	≥ 2 active maintainers	≥ 2 public production adopters	Full CI must stay green; release-blocking	N/A
2	≥ 1 active maintainer	≥ 1 pilot/internal user	Best-effort CI; not release-blocking	Can be downgraded after 2 major releases of inactivity
3	No maintainer	None confirmed	Minimal smoke tests; excluded from release criteria	May be removed after 1 full release cycle’s notice

Component = any service, layer, binding, or other module shipped under the OpenDAL umbrella.

---

Upgrade / Downgrade Workflow

1. Tier Proposal RFC – anyone may open, providing CI status, usage proof, maintainer list.
2. Core Review – core team responds within one week; component enters a ~1-release observation period.
3. Record Change – update SUPPORT.md, CHANGELOG, and release notes.

---

Communication & Tooling

• SUPPORT.md lists every component with its tier.
• Each component’s README shows a badge for quick status lookup.
• GitHub Actions auto-checks CI, maintainer activity, and public signals (downloads, stars) to flag drift.

---

Call for Feedback

• Are the criteria strict enough yet still attainable?
• Is one release cycle sufficient notice before retiring a Tier 3 component?
• What incentives would encourage volunteers or companies to adopt Tier 3 components?

Please share your thoughts—especially if you depend on, or might maintain, a component.
Together we can keep OpenDAL growing without compromising reliability.