Hi there! We're thrilled that you'd like to contribute to this project. Your help is essential for keeping it great.
Contributions to this project are released to the public under the project's open source license.
Please note that this project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms.
- Fork and clone the repository
- Create a new branch:
git checkout -b my-branch-name - Make your change, add tests, and make sure the tests still pass
- Push to your fork and submit a pull request
- Pat your self on the back and wait for your pull request to be reviewed and merged.
Here are a few things you can do that will increase the likelihood of your pull request being accepted:
- Write tests.
- Keep your change as focused as possible. If there are multiple changes you would like to make that are not dependent upon each other, consider submitting them as separate pull requests.
- Write a good commit message.
Details
Note: these instructions are for maintainers
- Update the version number in package.json and run
npm ito update the lockfile. This is also a good time to make sure that thedist/index.jsfile is up to date by runningnpm run build. - Go to Draft a new release in the Releases page.
- Make sure that the
Publish this Action to the GitHub Marketplacecheckbox is enabled
- Click "Choose a tag" and then "Create new tag", where the tag name
will be your version prefixed by a
v(e.g.v4.1.2). - Use a version number for the release title (e.g. "4.1.2").
- Add your release notes. If this is a major version make sure to include a small description of the biggest changes in the new version.
- Build the release executables by manually triggering this action. The output of this action will be a zip file that you should download, extract, and drag into the binaries section. There should be three files there: ending in
-linux,-macos, and-win.exe. - Click "Publish Release".
You now have a tag and release using the semver version you used
above. The last remaining thing to do is to move the dynamic version
identifier to match the current SHA. This allows users to adopt a
major version number (e.g. v1) in their workflows while
automatically getting all the
minor/patch updates.
To do this just checkout main, force-create a new annotated tag, and push it:
git tag -fa v5 -m "Updating v5 to 5.0.0"
git push origin v5 --force