Skip to content

Latest commit

 

History

History
131 lines (103 loc) · 5.77 KB

MAINTAINING.md

File metadata and controls

131 lines (103 loc) · 5.77 KB
Raw

Maintaining React-Bootstrap

This document is for people working on React-Bootstrap. It describes common tasks such as triaging or merging pull requests.

If you are interested in contributing to React-Bootstrap, you should check out the Contributing Guide.

Triaging Issues

New issues pop up every day. We need to identify urgent issues (such as nobody can use a component, or install React-Bootstrap), close and link duplicates, answer questions, etc. Please alert the gitter/react-bootstrap chat room of the urgent issues. We are using HuBoard which is a kanban style board to track and prioritize issues.

Merging a pull request

Please, make sure:

  • Travis build is green
  • At least one collaborator (other than you) approves the PR
    • Commenting "LGTM" (Looks good to me) or something of similar sorts is sufficient.
    • If it's a simple docs change or a typo fix, feel free to skip this step.
  • Commits follow the convention prescribed in the Contributing Guide.
    • This is very important, because the release process uses this to generate the changelog.
    • Commits are squashed. Each change is a single commit.
      • e.g. if the PR contains two changes such as [fixed] Some Bug and then [fixed] Some other unrelated bug it should be two separate changes.
      • e.g. if the first commit is [fixed] Some bug and the second commit is [fixed] failing tests for previous commit, you should squash them into a single commit
    • It's alright to ask the author of the pull request to fix any of the above.

Becoming a maintainer

If you are interested in becoming a react-bootstrap maintainer, start by reviewing issues and pull requests. Answer questions for those in need of troubleshooting. Join us in the gitter/react-bootstrap chat room. Once we see you helping, either we will reach out and ask you if you want to join or you can ask one of the organization owners to add you. We will try our best to be proactive in reaching out to those that are already helping out.

GitHub by default does not publicly state that you are a member of the organization. Please feel free to change that setting for yourself so others will know who's helping out. That can be configured on organization list page.

Being a maintainer is not an obligation. You can help when you have time and be less active when you don't. If you get a new job and get busy, that's alright.

Releases

Releases should include documentation, git tag, bower package preparation and finally the actual npm module publish. We have all of this automated by running ./tools/release from the root of the repository. PLEASE DO NOT RUN npm publish BY ITSELF. The release script will do that. We want to prevent issues like #325 and #218 from ever happening again. In order to run the release script you will need permission to publish to the package to npm. Those with this permission are in the publishers team

Note: The publishers team does exist. If you see 404 that means you just have no permissions to publish.

Example usages of the release script:

$ ./tools/release patch
$ ./tools/release minor
$ ./tools/release major
$ ./tools/release minor --pre beta

Note that the above commands will bump the semver version programmatically so you don't need to. Please be mindful to ensure that semver guidelines are followed. If it is discovered that we have pushed a release in violation of semver, than a patch release reverting the offending change should be pushed as soon as possible to correct the error. The offending change can then be re-applied and released with the proper version bump.

Live releasing the documentation

The documentation release script does a similar job to the release script except that it doesn't publish to npm. It will auto tag the current branch with a pre "docs" tag, and will push to documentation repository.

For a given tag (lets say 0.22.1) the first docs tag would be 0.22.1-docs.0. In order to tags to be incremental and in order to include all the previous docs changes, make sure that if a docs tags exists for the current release, that you start from that tag.

To live patch the documentation in between release follow these steps

  1. Find the latest documentation release.
  • Check the latest release tag (lets say v0.22.1).
  • Look for a docs-release tag for that version ex: v0.22.1-docs.X
  • If one exists, check-it-out. If not checkout the latest release tag.
  • Note: Checkout the tag and not master directly because some live documentation changes on master that could related to new components or updates for the upcoming release
  1. Create a new branch from there (for example git checkout -b docs/v0.22.1)
  2. Cherry-pick the commits you want to include in the live update git cherry-pick <commit-ish>...
  3. Use the release-docs script to push and tag to the documentation repository.

Note: The branch name you checkout to cherry-picked the commit is not enforced. Though keeping similar names ex: docs/<version> helps finding the branch easily.

Example usage of release-docs script:

$ ./tools/release-docs

Check everything is OK before releasing

Release tools have a very useful option --dry-run.

You can use it

  • to learn how releasing tools are working.
  • to ensure there are no side issues before you release anything.