Release Process

[janaakhterov]

Release Process

Hey everyone, after some discussion I've along with others have come to realize the way we separate our releases is problematic because it does not differenciate between SDK beta features and Hedera Services previewnet features. I think this distintion is necessary because it is a separation of concerns. Currently we have the following:

• Official Release:
  • This is currently the main branch
  • Contains the last sprints beta release along with any bug fixes that
    were applied to main directly.
• Beta Release:
  • This is currently the develop branch
  • Contains both the SDK beta features and Hedera Services previewnet features.

The issue in particular with this is that the SDK features can and should be stabalized after a single sprint of no change to said feature. However, Hedera Services previewnet features might be pushed back if issues are found. As of right now we incorrectly still merge the last sprints develop into main meaning sometimes we release previewnet features in our official release, e.g. the recent account allowance feature. So, I think a change is warranted and this is what I have in mind right now.

• Official Release:
  • This will always be our main branch
  • This release should be our non-breaking change API.
  • It should contain only requests which are avaiable on testnet and mainnet.
• Beta Release:
  • This will always be our develop branch
  • This release should contain all of our SDK beta features.
  • This should be up to date with main
  • Will only contain new SDK features
    • e.g. Our recent network changes using Math.random() would be here
  • Should only be released if new SDK features were implemented.
  • Should be released with a suffix of beta.N, e.g. v2.12.0-beta.1
  • If a sprint goes by without any changes to this beta release then it should be merged into main. Otherwise it stays on develop.
• Release Candidate:
  • A new branch labeled as rc/<version> should be created per release candidate
  • This release should only contain protobuf changes such as new requests.
  • This should be update to date with main
  • Will only be merged into main when Hedera Services supports the new requests on mainnet. This will likely require coordination with Simi.

User Stories

1. A new HIP is created for feature X. hedera-protobufs is updated with protobufs for feature X. Then, a new branch from main should be created with the name of rc/<version> where <version> is the version feature X is expected to hit mainnet.

2. A feature that hit mainnet is discovered to have a bug, and to fix this bug protobufs need to be updated. Then, main should be updated with the new protobufs and a fix should be implemented in a non-breaking way.

3. A bug is discovered in a recent beta release. Then, the develop branch should be updated with the fix, and another beta patch release should be released either during the sprint, or at the end of the sprint depending on the severity.

4. A bug is discovered in the latest official release. Then, main should be updated with the fix, and another patch release should be released either during the sprint, or at the end of the sprint depending on the severity.

5. A recent feature that was expected to hit mainnet on v0.24.0 is delayed to version 25. Then, rc/v0.24.0 should remove said feature. A new branch should be created if one does not already exist for version v0.25.0, and that branch should be updated with the new feature.

6. A older version of the SDK is found to have a bug. Then the latest main release should be tested for this bug, if the bug still exists it should be fixed on main. Otherwise, do nothing.

Current Release Process

• Create new release branch off main named release/v<X> where <X> is a semver version
• Update release version in the release branch
• Make sure Changelog is up to date in each PR
• Squash merge PR's using git directly into a release/X branch instead of using GitHub; leave the PRs open
• Fix all the possible merge conflicts that can arise
• Java:
  • Checkout variant/jdk7 and run git clean -ffdx to make sure branc his clean
  • Merge the release branch into variant/jdk7
  • Run ./gradlew sdk:assemble to check if the SDK builds
  • Release the SDK using ./gradlew sdk:uploadeArchieve
  • Checkout variant/jdk9 and run git clean -ffdx to make sure branc his clean
  • Merge the release branch into variant/jdk9
  • Run ./gradlew sdk:assemble to check if the SDK builds
  • Release the SDK using ./gradlew sdk:uploadeArchieve
  • Go to https://oss.sonatype.org and double check everything looks okay for a release
  • Hit "Close" on the release
  • Refresh page after a ~30s and hit "Publish" on that release
• JS:
  • Checkout the release branch
  • Run just publish or just publish beta if it's a beta release
  • Fix any potential issues that might have arised from merging several PRs
• GO:
  • Checkout the release branch
  • Run go build and then go test -tags unit -v
  • Fix any potential issues that might have arised from merging several PRs
  • Open the GitHub repo in browser
  • Create a new release on the release branch and copy over the changelog

[janaakhterov]

cc @rbair23 @SimiHunjan @Sean-Tedrow-LB @andrix10 @keirabee @easpaas @rickyrodmac

[easpaas]

I think this is good solution @danielakhterov.

[easpaas]

After consensus has been reached for this process, @danielakhterov could you add the final copy to the Hedera SDK Notion docs?

[janaakhterov]

Something @Sean-Tedrow-LB suggested, but hasn't had the time to write down here is that we should keep all features on their own version until they hit an official release. E.g. if we were to do an SDK network overhaul and implement a new Hedera feature we'd have a branch for each. Then when releasing we'd branch from main into release/X, merge both of these branches into that release, but without deleting the branch. This means if more progress needs to be made we'd be able to easily fix it on it's own branch and merge it into the new release branch for next sprint. The issue I see with this is it would require a lot of merging each release. I don't know if that is a huge problem, but when merging complex PRs it may be very problematic to do it right; especially because each of these branches will be long living with numerous changes. However, it is a solution.

[janaakhterov]

After talking with @easpaas we came to realize this issue may be a lot easier to solve if we had separate branches for each network inside of hedera-protobufs.