Skip to content

Latest commit

 

History

History
115 lines (89 loc) · 5.9 KB

CONTRIBUTING.md

File metadata and controls

115 lines (89 loc) · 5.9 KB
Raw

Contributing

Thank you for considering making contributions to pigeon. We welcome all messenger birds!

Contributing to this repo can mean many things such as participating in discussions or proposing new features, improvements or bug fixes. To ensure a smooth and timely workflow for all contributors, the general procedure for contributing has been established:

  1. If you would like to contribute, first do your best to check if discussions already exist as either a Github Issue or PR. Be sure to also check out our public Telegram Channel. Existing discussions will help you gain context on the current status of the proposed contribution or topic. If one does not exist, feel free to start one.
  2. If you would like to create a Github Issue, either open or find an issue you'd like to help with. If the issue already exists, attempt to participate in thoughtful discussion on that issue.
  3. If you would like to contribute:
    1. If the issue is a proposal, ensure that the proposal has been discussed and accepted.
    2. Ensure that nobody else has already begun working on this issue. If they have, make sure to contact them to potentially collaborate.
    3. If nobody has been assigned to the issue and you would like to work on it, make a comment on the issue to inform the community of your intentions to begin work.
    4. Follow standard GitHub best practices, i.e. fork the repo, branch from the HEAD of master, make commits, and submit a PR to master
      • For core developers working within the repo, to ensure a clear ownership of branches, branches must be named with the convention {moniker}/{issue#}-branch-name.
    5. Be sure to submit the PR in Draft mode. Submit your PR early, even if it's incomplete as this indicates to the community you're working on something and allows them to provide comments early in the development process.
    6. When the code is complete it can be marked Ready for Review and follow the PR readiness checklist.

Coding Guidelines

We follow the Cosmos SDK Coding Guidelines. Specifically:

  • API & Design SHOULD be proposed and reviewed before the main implementation.
  • Minimize code duplication
  • Define Acceptance tests or while implementing new features.
    • Prefer use of acceptance test framework, like gocuke
    • For unit tests or integration tests use go mock for creating mocks. Generate mock interface implementations using go generate.

Branching Model

The Paloma repos adheres to the trunk based development branching model and utilizes semantic versioning.

PR Targeting

Ensure that you base and target your PR against the master branch.

All feature additions should be targeted against master. Bug fixes for an outstanding release candidate should be targeted against the release candidate branch.

PR & Merge Procedure

  • Ensure the PR branch is rebased on master.
  • Ensure you provided unit tests and integration tests.
  • Merge the PR!

Release procedure

We follow semver (from v3.0.0):

  • major version update (eg 2.x.x -> 3.0.0) has API breaking changes or signals major feature update
  • minor version update (eg 2.1.x -> 2.2.0) has no API nor state machine breaking changes. It can provide new functionality or bug fixes.
  • patch version update (eg 2.1.0 -> 2.1.1) has no API nor state machine breaking changes nor new features. It only contains hot fixes.

Note, when the major version is 0, we adopt a 0-based versioning scheme:

  • major version update (eg 0.12.x -> 0.13.x) has API breaking changes or signals major feature update
  • minor version update (eg 0.12.1 -> 0.12.2) has no API nor state machine breaking changes. It can provide new functionality or bug fixes.

Major Release Procedure

All major changes related to major version update are first released for testnet. We use -betaX (eg 2.0.0-beta1, 2.0.0-beta2 ...) releases for testnet. Once the code is stabilized we create a release candidate (eg 2.0.0-rc1). If no issues are found the latest release candidate becomes the major release.

When a major release is ready to be made, perform the following:

  1. Create a release/vX.*.* release. branch off of the desired commit on master, e.g. release/v0.12.x or release/v1.x.x.
  2. Create a RELEASE_NOTES.md template.
  3. Ensure correct branch protection rules are enabled. This can be done generally using a regex such as release/v*.
  4. Create a branch off of the release branch that prepares the RELEASE_NOTES.md based on the changelog.
  5. Review and merge the release notes PR.
  6. Cut a release off of the release branch! Note, goreleaser should automatically create the release artifacts once the tag is pushed.
  7. Ensure changelog entries are updated on master, i.e. have the release date, version, and link to the release.

Minor Release Procedure

All changes should be merged into master, unless a change is needed against a specific release only.

When a change is needed in a current release, add the appropriate backport/* label to the PR and Mergify will automatically create a backport PR against the release branch. If a PR is already merged, you can comment on the PR for Mergify to create the backport PR via @Mergifyio backport release/vX.*.* (use the relevant release branch name).

When you are ready to cut a point release, perform steps 4-7 from the Major Release Procedure.