When releasing changes to the Kanda SDK, follow these guidelines to ensure a smooth and consistent release process.

1. Create a Release Branch

Create a release branch off the main branch. Name the branch using the semantic versioning convention.

Example:

git checkout main
git pull origin main
git checkout -b release/1.2.3

For preview packages, use the -preview.version convention.

Example:

git checkout main
git pull origin main
git checkout -b release/1.2.3-preview.3

2. Update the Package Manifest and changelog

Update the version field in the package.json file to match the desired release version.

Example:

{
  "name": "io.kanda.sdk",
  "version": "1.2.3",
  ...
}

You may also need to update the CHANGELOG.md file with relevant changes for the new package version using the Added, Changed, Fixed, Removed convention.

Commit the changes and push the release branch to the remote repository.

Example:

git add package.json
git commit -m "Bump version to 1.2.3"
git push origin release/1.2.3

3. Release the Package

To start the release process, make a Pull Request from the release branch targeting the main branch.

If SDK CI tools are set up for the repository, go to Bitbucket Pipelines. A release pipeline will be running for your release branch commit.

To release the package to the Kanda Package Registry and generate and upload documentation, press "Deploy" on the "Publish package" step.

4. Review and Confirm Deployment

Review the package diff and connected Jira issues. If everything looks good, confirm the deployment. The deployment can be tracked in the Bitbucket repository "Deployment" tab.

5. Availability

Once deployed, the package version will become available at npm.kanda.dk and documentation at docs.kanda.dk.

6. Merge Release Branch Back to Main

After completing the release, merge the release branch back to the main branch to ensure that the main branch is up to date with the latest changes.

Example:

git checkout main
git pull origin main
git merge release/1.2.3
git push origin main

If you get an error, which blocks you pushing the merge directly to main, you can also perform the merge with the Merge button in the PR.

7. Downstream Package Updates

Note that this does not mean downstream packages will automatically start using the new package version. They will have pinned a previous version and will need to release an update themselves to include the new package by default.

Provided the new package version is backward compatible, users can opt in to the new version using the Unity Package Manager before it is included by default in downstream packages.

By following these guidelines, you can ensure a smooth release process and maintain the consistency and reliability of the Kanda SDK.