MAINTAINERS.md
CHANGES.md. Looking at CHANGES.md would be a good stepping off point.grunt major, grunt minor, grunt patch to update the version number and generate all the dist files.CHANGES.md) into your commit. Add the new release number into your commit message. And push it up to the remote master branch.5.11.0). Copy/paste the entries you made in CHANGES.md into the release summary. Make sure the release is against the master branch.npm publish.For pull requests submitted from a forked version of the repo, the test suite won't run in Saucelabs so we haven't been able to know if tests fail in various browsers until after the PR is merged into master. This is deliberate by Saucelabs as a security measure to prevent external forks from doing malicious things to the repo.
There is a workaround however, so when a PR is submitted from an external fork, follow these steps to verify the tests don't fail in Saucelabs before merging the PR into master.
For this example, let's assume there's a new pull request (#123) from a branch of an external user's fork (external-user/new-branch)
git checkout -b integration-123git remote add external-user [email protected]:external-user/medium-editor.gitgit fetch external-usergit merge external-user/new-branchgit pushThat's it. Pushing the branch up should kick off a travis build, which will cause the tests to run in Saucelabs. Github is smart enough to link the existing pull request to that build and reflect the status of the build (including the results from Saucelabs) on the PR summary page!