Skip to content
This repository was archived by the owner on Mar 31, 2026. It is now read-only.

CONTRIBUTING.md

Latest commit

 

History

History
71 lines (48 loc) · 2.68 KB

CONTRIBUTING.md

File metadata and controls

71 lines (48 loc) · 2.68 KB

🦦 Releasing

  1. Go to the main branch and ensure it is up to date with the remote:
git checkout main
git pull
  1. Run the script that will generate the CHANGELOG for you:
sh tool/release_ready.sh <new-version>

Note 💡 : You should follow semantic versioning and bump according to the changes the new version makes.

<new-version>: The version of this new extension release, for example: 0.2.1

The release_ready script will:

  • Create a new branch just for this release and checkout to it.
  • Automatically update the CHANGELOG file with the associated changes.
  1. Manually remove the (deps-dev) scope or other entries of the conventional commits entries in the CHANGELOG
  2. Add the changes and commit with the commit message that the release_ready script outputted.
  3. Raise a Pull Request, the title should be the same as the commit message outputted by the release_ready script.
  4. When the Pull Request is merged, tag a new release to the commit. When adding the tag ensure:
    • The tag is pointing to the commit that you recently merged.
    • The title of the tag should be v
    • The title of the release should be v
    • The description should be a raw copy of the CHANGELOG’s file version’s body you recently crafted (without the version header). If in doubt, see the other released tags as an example.
  5. After the release is tagged the new changes will be available by the the following syntax:
VeryGoodOpenSource/..@v<new-version>

Where:

  • <new-version>: The version of this new workflow or action, for example: 0.2.1
  1. Go to the main branch and ensure it is up to date with the remote:
git checkout main
git pull
  1. Retag the major release.

For the Workflow or Action to be updated for those users using the @<major-version syntax we will require to retag the major release.

sh tool/retag_v<major-version>.sh <new-version>

Where:

  • <major-version>: Is the major version of the release, for example in 2.16.3 the major version is 2. For more information see the semantic versioning documentation.
  • <new-version>: The version of this new workflow or action, for example: 0.2.1.

If your change is a breaking change and requires a new major release you should update the name of the retag script and its v<major-version> instances.

  1. After the retag the new changes will be available by the the following syntax:
VeryGoodOpenSource/..@v<major-version>

Where: <major-version>: Is the major version of the release, for example in 2.16.3 the major version is 2. For more information see the semantic versioning documentation.