Alpha Release Strategy

Why

This workflow is for making sure that we can:

• release the alpha version without any SDK user implicitly downloading it
• patch the alpha version automatically without SDK regeneration
• avoid publishing conflicts with other core library developers

Core Library

When releasing the feature for the first time:

1. Create a feature branch and commit and push your changes.
2. Create a PR with alpha as the base branch. Get it approved and merged.
3. Run the Release action on alpha branch with the prerelease option.

When releasing an update to the feature:

1. Create a PR with alpha as the base branch. Get it approved and merged.
2. Run the Release action on alpha branch with the prerelease option.

When merging changes from master branch that you want to release:

1. Create a new feature branch with changes from master and create a PR with alpha base branch. You may get merge conflicts.
2. For the versions in the package-lock.json and package.json, match the versions in alpha. In other words, the version should not be changed in package.json on alpha branch.
3. Run the Release action on alpha branch with the prerelease option.

When preparing for production release:

1. Create PR for alpha and update all the versions in the package-lock.json and package.json files so that they match master just like a brand new feature branch.
2. Create PR from alpha to master
3. Merge your PR into master
4. Release as normal(patch, minor or major). Do not use prerelease.

About the prerelease option in the Release Action

The action will publish all the changed libraries with a "prepatch" version. In other words, if the master branch was at 0.3.3 when you created a feature branch from it, the action will publish 0.3.4-alpha.0.

The next action runs on the alpha branch will bump the alpha version. For example, 0.3.4-alpha.0 will become 0.3.4-alpha.1 and so on.

CodeGen

The SDK won't use alpha versions until you explicitly say so. Update the version specifier that is generated to allow only alpha releases in the next patch version.

For example, if it was "^0.3.2", change it to ">=0.3.3-alpha.0 <0.3.3".

Why the <0.3.3 constraint? In our example, the latest master branch version is 0.3.2. So if someone releases a patch in the master branch before the feature branch is closed, it might break the SDK.

Remember to change it back to the latest version in CodeGen when you're done with the alpha versions. For example, if the master branch is using 0.3.4, change CodeGen back to using "^0.3.4".