APM Server is open source, and we love to receive contributions from our community — you!
There are many ways to contribute, from writing tutorials or blog posts, improving the documentation, submitting bug reports and feature requests, or writing code.
If you want to be rewarded for your contributions, # for the Elastic Contributor Program. Each time you make a valid contribution, you’ll earn points that increase your chances of winning prizes and being recognized as a top contributor.
GitHub is reserved for bug reports and feature requests; it is not the place for general questions. If you have a question or an unconfirmed bug, please visit our discussion forum; feedback and ideas are always welcome.
If you have a bug fix or new feature that you would like to contribute, please find or open an issue first. It's important to talk about what you would like to do, as there may already be someone working on it, or there may be context to be aware of before implementing the change.
Development instructions are available in the project readme.
When submitting changes, add an entry to the changelog, describing the enhancement or fix that your PR is adding.
Please read our pull request template, which includes the information we care about the most when submitting new changes.
All feature development and most bug fixes hit the main branch first. Pull requests should be reviewed by someone with commit access. Once approved, the author of the pull request, or reviewer if the author does not have commit access, should "Squash and merge".
Before or during review, a committer will label the pull request with backport-<branch> for the
prior release branches to which the changes should be backported. For example, say the next minor
release is 8.2, and a bug fix is implemented which should be backported to 8.1.next. The pull request
should be developed against main, with the backport-8.1 label applied. Once the pull request is merged,
it will be automatically backported to the 8.1 branch.
Once a version is released, new features are frozen for that minor version and will not be backported. For example, if 7.10 was just released, the soonest a new feature will be released is 7.11, not 7.10.1.
Breaking changes may need to wait until the next major version. See semver for general information about major/minor versions.
Bug fixes may be backported on a case by case basis. The committer of the original pull request, typically the author, is responsible for backporting the changes to the target versions. Straightforward backports may be merged without review.
As an alternative to backport automation through backport-<branch> labels (e.g. when automation fails),
we sometimes use Backport.
This is a collection of example PRs for additions occuring somewhat frequently.