chore(pyroscope): mark pyroscope components as GA

[korniltsev]

PR Description

Dealing with stability-preview is a burden for both internal grafana users and external.
Let's mark pyroscope.ebpf, pyroscope.java, pyroscope.scrape, pyroscope.write, discovery.process as GA.

Which issue(s) this PR fixes

Notes to the Reviewer

PR Checklist

• CHANGELOG.md updated
• Documentation added
• Tests updated
• Config converters updated

[simonswine]

LGTM Either that. I probably would even argue that the default stability-level for Alloy should be "public-preview"

[korniltsev]

Let's wait for more approves from @rfratto @tpaschalis @petethepig @Rperry2174

[rfratto]

I don’t think we should mark components GA because it’s a burden. If the components are stable, are ready for production use, and they won’t have any breaking changes, then they qualify for GA. Are they at that state yet?

[rfratto]

For reference, GA means these two things:

• It follows the definitions of the Grafana Labs release cycle
• Breaking changes will no longer happen in minor releases

While not documented, we also are trying to aim to release a new major version no more frequently than yearly.

I’m comfortable with this PR being merged if these components are ready, but I want to make sure the implications are known first.

[petethepig]

From my perspective it matches all GA criteria.

@korniltsev Assuming we are fine with a year without making breaking changes I think this is good to go.

[Rperry2174]

Discussed with the team and also agree that we meet the GA criteria! 👍

[rfratto]

Given the above, I'm on board 👍