RELEASE.md

Release Guidelines

If you need to release a new version of the SVGO Action, follow the guidelines found in this document.

• Automated Releases (Preferred)
• Manual Releases (Discouraged)
• Creating a GitHub Release
• Major Releases
• Non-current Releases

Automated Releases (Preferred)

To release a new version follow these steps:

1. Manually trigger the release workflow from the main branch; Use an update type in accordance with Semantic Versioning. This will create a Pull Request that start the release process.
2. Follow the instructions in the description of the created Pull Request.

Manual Releases (Discouraged)

If it's not possible to use automated releases, or if something goes wrong with the automatic release process, you can follow these steps to release a new version (using v4.3.2 as an example):

1. Make sure that your local copy of the repository is up-to-date. Either sync:

   git checkout main
   git pull origin main

   Or use a fresh clone:

   git clone [email protected]:ericcornelissen/svgo-action.git

2. Update the contents of the lib/ directory using:

   npm run build

3. Update the version number in the package manifest and lockfile:

   npm version --no-git-tag-version v4.3.2

   If that fails, change the value of the version field in package.json to the new version:

   -  "version": "3.1.3",
   +  "version": "3.1.4",

   and update the version number in package-lock.json using npm install (after updating package.json), which will sync the version number.

4. Update the changelog:

   node script/bump-changelog.js

   If that fails, manually add the following text after the ## [Unreleased] line:

   - _No changes yet_
   
   ## [3.1.4] - YYYY-MM-DD

   The date should follow the year-month-day format where single-digit months and days should be prefixed with a 0 (e.g. 2022-01-01).

5. Commit the changes to a new release branch and push using:

   git checkout -b release-$(sha1sum package-lock.json | awk '{print $1}')
   git add lib/ CHANGELOG.md package.json package-lock.json
   git commit --no-verify --message "chore: version bump"
   git checkout -b release-$(sha1sum package-lock.json | awk '{print $1}')

   The --no-verify option is required to commit the changes in lib/.

6. Create a Pull Request to merge the release branch into main.

7. Merge the Pull Request if the changes look OK and all continuous integration checks are passing.

   [!NOTE] At this point, the continuous delivery automation may pick up and complete the release process. Check whether or not this happens. If no, or only partially, continue following the remaining steps.

8. Immediately after the Pull Request is merged, sync the main branch:

   git checkout main
   git pull origin main

9. Create a git tag for the new version:

   git tag v4.3.2

10. Update the v4 branch to point to the same commit as the new tag:

    git checkout v4
    git merge main

11. Push the v4 branch and new tag:

    git push origin v4 v4.3.2

12. Create a GitHub Release.

Creating a GitHub Release

Create a new GitHub Release for the git tag of the new release. The release title should be "Release {version}" (e.g. "Release v4.3.2"). The release text should be the changes from the changelog for the version (including links).

Ensure the version is published to the GitHub Marketplace as well.

Major Releases

For major releases, some additional steps are required. This may include:

• Ensure any references to the major version in the documentation (external and internal) are updated.
• Update the continuous delivery workflow to mark only releases for the new major version as latest.
• Update continuous integration workflows to run on the old and new major version branches (vX, main-vX, v(X-1), and main-v(X-1)).
• Update the issue templates to align with the new major version.
• Update the release Pull Request template title and body for the new major version.

Make sure these additional changes are included in the release Pull Request.

Non-current Releases

When releasing an older version of the project, refer to the Release Guidelines (RELEASE.md) of the respective main branch instead.