This document explains the release strategy for artifacts in this organization.
Given the current major release of 1.0, projects in this organization maintain the following active branches.
- main: The next major release. This is the branch where all merges take place and code moves fast.
- 1.x: The next minor release. Once a change is merged into
main, decide whether to backport it to1.x.
Label PRs with the next major version label (e.g. 2.0.0) and merge changes into main. Label PRs that you believe need to be backported as 1.x. Backport PRs by checking out the versioned branch, cherry-pick changes and open a PR against each target backport branch.
Do not create branches in the upstream repo, use your fork, for the exception to long-lasting feature branches that require active collaboration from multiple developers. Name feature branches feature/<name>. Once the work is merged to main, please make sure to delete the feature branch.
The release process is standard across repositories in this org and is run by a release manager volunteering from amongst maintainers.
- Create a tag, e.g. 1.0.0, and push it to this GitHub repository.
- The release-drafter.yml will be automatically kicked off and a draft release will be created.
- This draft release triggers the jenkins release workflow as a result of which the sdk is released on maven central. Please note that the release workflow is triggered only if created release is in draft state.
- Once the above release workflow is successful, the drafted release on GitHub is published automatically.
- Increment "version" in build.gradle to the next iteration, e.g. v1.0.1.
The snapshots builds are published to sonatype using publish-snapshots.yml workflow. Each push event to the main branch triggers this workflow.