Skip to content

Latest commit

 

History

History
45 lines (23 loc) · 2.97 KB

CONTRIBUTING.md

File metadata and controls

45 lines (23 loc) · 2.97 KB
Raw

How to Contribute to Hops

First off, we really value your contribution. Thanks for wanting to help us with your time and talent! 🌈

Did you find a bug?

  • Ensure the bug was not already reported by searching on GitHub under Issues.

  • If you're unable to find an open issue addressing the problem, open a new one. Be sure to include a title and clear description, as much relevant information as possible, and a code sample or an executable test case demonstrating the expected behavior that is not occurring.

Did you write a patch that fixes a bug?

  • Open a new GitHub pull request with the patch.

  • Ensure the PR description clearly describes the problem and solution. Include the relevant issue number if applicable.

Do you intend to add a new feature or change an existing one?

  • Suggest your change as an issue on GitHub to collect positive feedback about the proposal before starting to actually write code.

  • Before submitting code, please make sure you update or extend the existing test cases, documentation and run yarn test in Hops' root folder.

All code in this repository is expected to be formatted using prettier, and we will only merge valid conventional commits in order to enable automatic versioning.

Releasing a new version

Releasing Hops requires the environment variable GH_TOKEN to be set to a valid GitHub access token with the public_repo scope in order to publish the release notes to the GitHub releases page.

Branching in Hops

We are using the master branch as our staging branch and we have a maximum of two active release branches at a time. The release branches follow the naming convention of vN.x (where N is the major version number of that release).

All PRs (except for PRs generated by renovate or release PRs) must be made against master and include in their description, and through a label, for which release they are intended.

We have appointed branch maintainers for each of the release branches, who will take care of cherry-picking the required changes.

During preparation of a new release the branch maintainer for that release will cherry-pick the required commits from master into a PR targeting the release branch.

If conflicts arise during cherry-picking or if a backport needs to be re-created, the branch maintainer may contact the original author to resolve these issues (ie. the original author will resolve the conflicts or re-create a path for an older release branch).

Once the release preparation PR is merged into the release branch, the branch maintainer will release the packages to the npm registry.

Thanks! 💚

Hops Team