Skip to content

Latest commit

 

History

History
105 lines (65 loc) · 5.12 KB

CONTRIBUTING.md

File metadata and controls

105 lines (65 loc) · 5.12 KB
Raw

Sentry

Contributing to the Sentry SDK for Symfony

We welcome contributions to sentry-symfony by the community.

Please search the issue tracker before creating a new issue (a problem or an improvement request). Please also ask in our Sentry Community on Discord before submitting a new issue. There is a ton of great people in our Discord community ready to help you!

If you feel that you can fix or implement it yourself, please read on to learn how to submit your changes.

Submitting changes

  • Setup the development environment.
  • Clone the sentry-symfony repository and prepare necessary changes.
  • Add tests for your changes to tests/.
  • Run tests and make sure all of them pass.
  • Submit a pull request, referencing any issues it addresses.

We will review your pull request as soon as possible. Thank you for contributing!

Development environment

Clone the repository

git clone git@github.com:getsentry/sentry-symfony.git

Make sure that you have PHP 7.2+ installed. Version 7.4 or higher is required to run style checkers. On macOS, we recommend using brew to install PHP. For Windows, we recommend an official PHP.net release.

Install the dependencies

Dependencies are managed through Composer:

composer install

Running tests

Tests can then be run via PHPUnit:

vendor/bin/phpunit

Releasing a new version

(only relevant for Sentry employees)

Prerequisites:

  • All changes that should be released must be in the master branch.
  • Every commit should follow the Commit Message Format convention.

Manual Process:

This will trigger Craft to prepare everything needed for a release. (For more information see craft prepare) At the end of this process, a release issue is created in the Publish repository. (Example release issue: getsentry/publish#815)

Now one of the persons with release privileges (most probably your engineering manager) will review this Issue and then add the accepted label to the issue.

There are always two persons involved in a release.

If you are in a hurry and the release should be out immediately there is a Slack channel called #proj-release-approval where you can see your release issue and where you can ping people to please have a look immediately.

When the release issue is labeled accepted Craft is triggered again to publish the release to all the right platforms. (See craft publish for more information). At the end of this process, the release issue on GitHub will be closed and the release is completed! Congratulations!

There is a sequence diagram visualizing all this in the README.md of the Publish repository.

Versioning Policy

This project follows semver, with three additions:

  • Semver says that major version 0 can include breaking changes at any time. Still, it is common practice to assume that only 0.x releases (minor versions) can contain breaking changes while 0.x.y releases (patch versions) are used for backwards-compatible changes (bugfixes and features). This project also follows that practice.

  • All undocumented APIs are considered internal. They are not part of this contract.

  • Certain features (e.g. integrations) may be explicitly called out as "experimental" or "unstable" in the documentation. They come with their own versioning policy described in the documentation.

We recommend pinning your version requirements against 1.x.* or 1.x.y. Either one of the following is fine:

"sentry/sentry": "^1.0",
"sentry/sentry": "^1",

A major release N implies the previous release N-1 will no longer receive updates. We generally do not backport bugfixes to older versions unless they are security relevant. However, feel free to ask for backports of specific commits on the bug tracker.

Commit message format guidelines

See the documentation on commit messages here:

https://develop.sentry.dev/commit-messages/#commit-message-format