Document requirements for patch releases

[codeboten]

We had a relatively bad bug on 0.55.0 which would crash the collector when the telemetry level was set to none. This did not affect the default config. Is this enough for a patch release while we are still in v0.x?

Follow up from July 13 SIG meeting, we need to define the requirements for a patch release.

[mx-psi]

On the SIG we discussed that doing a release takes a significant amount of effort, and we have a very short release cycle, so we should have a high bar for when to make bugfix releases.

Here is a list of criteria, collating some of my own with some that were reported on the SIG's meeting:

1. The bug started happening on the latest version (no v0.N.1 bugfix release for a bug from v0.N-2)
2. The bug is sufficiently bad. This requires a judgement call but there are some issues that we can classify as 'definitely bad':
   • the Collector crashes reliably
   • the Collector fails to start under an accepted configuration
   • there is significant data loss
   • the Collector negatively affects its environment (e.g. messes up the OS)
3. The bug is detected soon enough after the release (e.g. in the first 3 working days after artifacts are released)
4. The bug happens in common setups. For example (not necessary to fit all of these):
   • No platform-specific bugs outside of Linux with amd64/arm64
   • It happens with the default configuration or a commonly used one
   • It is reported by multiple people on Github or Slack
5. The bug has no workaround or the workaround is significantly harder to put in place than updating the version (e.g. changing the configuration to a specific value is easy enough and should exclude making a bugfix release)

Some of these need a judgement call, we should defer to maintainers to make that judgement call.

For the specific case of #5641, with these guidelines we should not make a bugfix release: although it met 1,2 & 3, it did not meet 5 (and it's unclear if it met 4).