Skip to content

Latest commit

 

History

History
70 lines (43 loc) · 3.19 KB

CONTRIBUTING.md

File metadata and controls

70 lines (43 loc) · 3.19 KB
Raw

Contributing

Pull requests are welcome, please keep conversations and commit messages civil.

  1. Fork, then clone the repo.

  2. Set up your machine.

    yarn && yarn bootstrap

  3. Make sure the tests pass.

    yarn test

  4. Make your change. Add tests for your change. Make the linter and tests pass.

    1. Document changes using the jsdoc standards to ensure that our code self-generates good documentation.

      build the jsdoc site, the files will be outputted to ./build/docs/

      yarn generate-docs

      Validate that your generated documentation is what you intended, as documentation gets autogenerated from master.

    2. Run prettier to format code to comply with code style (Modified AirBnB Rule set: ES Lint Config)

      yarn format

    3. Make sure sure the linter and unit tests pass and the docs can be generated.

      yarn test

  5. Push to your fork and submit a pull request and wait for peer review.

    We may suggest some changes or improvements or alternatives.

    Some things that will increase the chance that your pull request is accepted:

    1. Your code must be documented inline via jsdoc annotations, tested, and pass the linter.
    2. Your changes must not break the existing library API without good justification.
    3. Your commit messages should be reasonable. (git rebase -i head~n choose the r option to reword you commits).

This guide is loosely based off of factory_bot_rails contributing.md which is referenced here GitHub's Contributing Guidelines blog post

Releasing a new version

Once a pull request has been reviewed and merged new versions of all packages can be released by any of the maintainers. This is an automated process driven by Github Release.

  1. Check the latest version number under releases and decide if the changes to be released require a MAJOR, MINOR or PATCH release according to semantic versioning:

    1. MAJOR version when you make incompatible API changes (e.g. 1.15.0 -> 2.0.0)
    2. MINOR version when you add functionality in a backwards-compatible manner (e.g. 1.15.0 -> 1.16.0)
    3. PATCH version when you make backwards-compatible bug fixes (e.g. 1.15.0 -> 1.15.1

  2. Create a new release by incrementing the correct version number using the Github Releases user interface.

    1. Be sure not to save any draft releases! (as they'll also trigger step 3 below since Github creates a new tag for draft releases).
    2. The tag version and release title is expected to be the same and in the following format: v1.43.0

  3. The new tag will kick off a Travis build and using will automatically release all packages using the new version specified. (See scripts/publish.sh for details).