- Questions
- Bugs and Issues
- Documentation Updates
- Feature Requests
- Submitting a Pull Request
- Merging a Pull Request
- Releasing
Have a question? Want to start a discussion? For now, you can simply Open a New Discussion, and choose a fitting category and title.
If you think you've found a bug, make sure you review and fill out a Bug Report before starting any work. This will ensure for both yourself and the maintainers that the issue in question can be properly confirmed, reproduced, smoke tested, etc. Once done, if you want to try to fix the issue yourself, go ahead and follow our Submitting a Pull Request guide. Contributions are welcome and encouraged!
Our documentation update request requirements are similar to the requirements for Bugs and Issues.
For feature requests, you can start by reviewing and filling out a Feature Request. Unlike bug fixes, Feature Requests will likely require more discussion from the maintainers, including whether or not it is consistent with our overall architectural goals, our timeline and priorities, and the like. Once done, assuming you've gotten a 👍 to work on the feature, go ahead and follow our Submitting a Pull Request guide.
Before submitting a pull request, make sure you've reviewed and filled out an appropriate Issue. We recommend doing this before starting any work, just in case an issue already exists, or it's unlikely the maintainers will be able to review the PR because it e.g. lacks sufficient reproduction steps. In addition, we recommend the following:
- We use conventional commits. Please try to prefix your commits according to the type of changes you're making, and try to be as descriptive as possible in your commit messages. For example:
- For Bug Fixes:
fix: foo by bar
- For Features:
feat: add video feat
- For Documentation Updates:
docs: update audio copy
-
Make sure you base your branch off of the latest in
main
, e.g.git checkout -b my-fix-for-foo main
-
When issuing your Pull Request, be sure to Link it to the corresponding issue(s)
-
Add any additional comments to your PR's description that will help the reviewer(s), such as call outs, open questions, areas that merit extra attention, etc.
-
When addressing any feedback, you can simply add it as new commits.
-
We use a rebase strategy when merging PR branches into
main
. If your branch has merge conflicts, if possible, please try to resolve them by doing agit rebase
ontomain
and then doing agit push --force-with-lease
. For example:git fetch upstream git rebase --onto main your-old-base my-fix-for-foo ... resolve any conflicts git push --force-with-lease
(See the git docs for more details on
git rebase --onto
)
When you choose to squash and merge be sure to prefix the commit message
with fix:
, feat:
or similar according to
conventional commits.
- Visit the GitHub Actions tab and select the "CD" action in the left sidebar.
- Click the "Run workflow" dropdown and choose the correct
Version
on themain
branch.- In the Use workflow from select box, make sure Branch: main is selected.
- In the Version select box, choose the appropriate value:
- If the commit messages in this release were written using the correct conventional commit style, select
conventional
. - If the commit messages aren't accurate, manually choose the correct semver version
patch
,minor
,major
.
- If the commit messages in this release were written using the correct conventional commit style, select
- When you're confident with your choices, click the green Run workflow button to start the release process.
- After a few minutes, a new release will be published. This includes an NPM package, new version tags, and a GitHub release.
This repo uses conventional commits and GitHub Actions for continuous deployment (CD).
If you're unfamiliar with conventional commits, it's a good idea to review the link above before continuing.
Here's a quick summary of how we use conventional commits in this repository:
- Commit messages prefixed with
fix:
will notify CD that the release is minimally apatch
release. - Commit messages prefixed with
feat:
will notify CD that the release is minimally aminor
release. - Commit messages containing
BREAKING CHANGE
in the footer will notify CD that the release is minimally amajor
release. - All other conventional commits have no impact on the versioning.
To proceed with a release, you should be confident that the commits in your upcoming release accurately reflect the type of version that you intend to release.
Here's how you can review the commits you're about to release:
- Visit https://github.com/muxinc/media-chrome/compare
- In the base select box, choose the tag applied to the previous release. Keep
main
for the compare select box value. - Review the list of commits to see if they are appropriately using conventional commits.
Note: if you're uncertain about particular commits, you may want to reach out to the author of said commit(s) for clarity
- Visit the GitHub Actions tab and select the "CD" action in the left sidebar.
- Click the "Run workflow" dropdown and choose the correct
Version
on themain
branch.- In the Use workflow from select box, make sure Branch: main is selected.
- In the Version select box, choose the appropriate value:
- If the commit messages in this release were written using the correct conventional commit style, select
conventional
. - If the commit messages aren't accurate, manually choose the correct semver version
patch
,minor
,major
.
- If the commit messages in this release were written using the correct conventional commit style, select
- When you're confident with your choices, click the green Run workflow button to start the release process.
- After a few minutes, a new release will be published. This includes an NPM package, new version tags, and a GitHub release.
- That's it! Nice work.