-
-
Notifications
You must be signed in to change notification settings - Fork 538
Development process
This document describes the process in how the extension is developed.
Before publishing a new version of the extension, we make a release draft for this version, where we document changes. The draft name should be in a SemVer format. The idea is a release draft is reserved for a future release tag.
We leverage release drafter to automate this drafting based off our defined label mappings.
This draft will be released automatically if a tag with the same name is pushed to the repository.
Publishing is normally done via manual trigger of the release extension GitHub Actions.
However it can still be done manually if needed. The steps below outline this:
Ensure that you are on the latest master (or patch) branch.
Ensure that you have remote set to origin to web-scrobbler/web-scrobbler.
Then run:
> ./release-extension.sh <type>where <type> is any release type: e.g. major, minor, or patch.
This command will do the following actions:
- Update the extension version in the manifest file.
- Commit changes, create a new tag for the new version.
- Push the commit and the tag to origin.
After the new tag is pushed to origin, the new version of the extension is published on Chrome Web Store and Addons.Mozilla.org automatically, as well as the draft release of this version is published on GitHub.
The list of supported websites on the extension website is updated automatically on every release.
Generally, patch releases should contains bug-fixes only. As an exception, they could contain a new connector for a popular website.
It's strongly recommended to use separate branches to publish patch updates. The format of the branch name follows a semver format; begins with v prefix and has x instead of patch number, e.g. v2.12.x.
If you want to use a commit from master in patch version, you can cherry-pick it using git cherry-pick %commit% when you're on patch branch.