Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[docs] Add bugfix release criteria #5707

Merged
merged 4 commits into from
Jul 25, 2022
Merged

[docs] Add bugfix release criteria #5707

Changes from 3 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
73ab67a
Add bugfix release criteria
mx-psi Jul 19, 2022
aeddc24
Apply suggestions from code review
mx-psi Jul 19, 2022
9343f6c
Fix sentence
mx-psi Jul 19, 2022
906687d
Reword last sentence
mx-psi Jul 20, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 25 additions & 0 deletions docs/release.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -98,6 +98,31 @@ The last step of the release process creates artifacts for the new version of th

1. `unknown revision internal/coreinternal/v0.55.0` -- This is typically an indication that there's a dependency on a new module. You can fix it by adding a new `replaces` entry to the `go.mod` for the affected module.

## Bugfix releases

### Bugfix release criteria

Both `opentelemetry-collector` and `opentelemetry-collector-contrib` have very short 2 week release cycles. Because of this, we put a high bar when considering making a patch release, to avoid wasting engineering time unnecessarily.

When considering making a bugfix release on the `v0.N.x` release cycle, the bug in question needs to fulfill the following criteria:

1. The bug was introduced on the `v0.N.x` release cycle.
2. The bug has been reported within the first 3 working days after the official binaries were released.
3. The bug has no workaround or the workaround is significantly harder to put in place than updating the version. Examples of simple workarounds are:
- Reverting a feature gate.
- Changing the configuration to an easy to find value.
4. The bug happens in common setups. To gauge this, maintainers can consider the following:
- The bug is not specific to an uncommon platform
- The bug happens with the default configuration or with a commonly used one (e.g. has been reported by multiple people)
5. The bug is sufficiently severe. For example (non-exhaustive list):
- The bug makes the Collector crash reliably
- The bug makes the Collector fails to start under an accepted configuration
- The bug produces significant data loss
- The bug makes the Collector negatively affect its environment (e.g. significantly affects its host machine)

The OpenTelemetry Collector maintainers will ultimately have the responsibility to assess if a given bug fulfills all the necessary criteria.
Exceptions may be granted in a case-by-case basis if there is widespread consensus that a bugfix release should be done despite the above rules.
Copy link
Member Author

@mx-psi mx-psi Jul 19, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this last line be here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the wiggle room, but I think ultimately the "case-by-case" basis is based on the maintainer's judgement. Could modify the line above to be "The OpenTelemetry Collector maintainers will ultimately have the responsibility to assess if a given bug fulfills all the necessary criteria, or should be patched anyways".

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reworded


## Release schedule

| Date | Version | Release manager |
Expand Down