chore: Update hedera-services to rename develop as main

.github/workflows/flow-artifact-determinism.yaml

@@ -35,7 +35,7 @@ on:
         default: "21.0.4"
   push:
     branches:
-      - develop
+      - main
       - 'release/**'
     tags:
       - 'v*.*.*'

.github/workflows/node-flow-build-application.yaml

@@ -50,7 +50,6 @@ on:
         default: "temurin"
   push:
     branches:
-      - develop
       - main
       - 'release/*'
 
@@ -124,7 +123,7 @@ jobs:
         with:
           workflow: .github/workflows/node-flow-deploy-release-artifact.yaml
           repo: hashgraph/hedera-services # ensure we are executing in the hashgraph org
-          ref: develop # ensure we are always using the workflow definition from the develop branch
+          ref: main # ensure we are always using the workflow definition from the main branch
           token: ${{ secrets.GH_ACCESS_TOKEN }}
           inputs: '{
             "ref": "${{ steps.workflow-inputs.outputs.input-ref }}",

.github/workflows/node-flow-deploy-release-artifact.yaml

@@ -150,7 +150,7 @@ jobs:
         uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
         with:
           fetch-depth: '0'
-          ref: develop
+          ref: main
           token: ${{ secrets.GH_ACCESS_TOKEN }}
 
       - name: Trigger ZXF Prepare Extended Test Suite
@@ -159,7 +159,7 @@ jobs:
         with:
           workflow: .github/workflows/zxf-prepare-extended-test-suite.yaml
           repo: hashgraph/hedera-services # ensure we are executing in the hashgraph org
-          ref: develop # ensure we are always using the workflow definition from the develop branch
+          ref: main # ensure we are always using the workflow definition from the main branch
           token: ${{ secrets.GH_ACCESS_TOKEN }}
           inputs: '{ "ref": "${{ inputs.ref }}" }'
 
@@ -171,7 +171,7 @@ jobs:
         with:
           workflow: .github/workflows/node-zxf-deploy-integration.yaml
           repo: hashgraph/hedera-services # ensure we are executing in the hashgraph org
-          ref: develop # ensure we are always using the workflow definition from the develop branch
+          ref: main # ensure we are always using the workflow definition from the main branch
           token: ${{ secrets.GH_ACCESS_TOKEN }}
           inputs: '{
               "ref": "${{ inputs.ref }}",
@@ -195,7 +195,7 @@ jobs:
         uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
         with:
           token: ${{ secrets.GH_ACCESS_TOKEN }}
-          ref: develop
+          ref: main
           fetch-depth: '0'
 
       - name: Checkout Hedera Protobufs Code

.github/workflows/node-zxcron-develop-fsts-regression.yaml

@@ -14,7 +14,7 @@
 # limitations under the License.
 ##
 
-name: "ZXCron: [Node] Develop JRS Tests"
+name: "ZXCron: [Node] Main JRS Tests"
 on:
   workflow_dispatch:
 

.github/workflows/node-zxf-snyk-monitor.yaml

@@ -19,7 +19,7 @@ name: "ZXF: Snyk Monitor"
 on:
   push:
     branches:
-      - develop
+      - main
   workflow_dispatch:
 
 permissions:

.github/workflows/platform-zxcron-develop-jrs-regression.yaml

@@ -14,7 +14,7 @@
 # limitations under the License.
 ##
 
-name: "ZXCron: [Platform] Develop JRS Regression"
+name: "ZXCron: [Platform] Main JRS Regression"
 on:
   schedule:
     - cron: '30 5 * * *'

.github/workflows/zxc-jrs-regression.yaml

@@ -486,8 +486,8 @@ jobs:
             fi
 
             if [[ -n "${HEDERA_TESTS_ENABLED}" && "${HEDERA_TESTS_ENABLED}" = true ]]; then
-              # Override for the develop branch
-              if [[ "${SLACK_BRANCH}" != "develop" ]]; then
+              # Override for the main branch
+              if [[ "${SLACK_BRANCH}" != "main" ]]; then
                 SLACK_SUMMARY="hedera-gcp-${SLACK_BRANCH}-summary"
                 SLACK_RESULTS="hedera-gcp-${SLACK_BRANCH}-regression"
               else

.github/workflows/zxcron-extended-test-suite.yaml

@@ -57,12 +57,12 @@ jobs:
         uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
         with:
           fetch-depth: '0'
-          ref: develop
+          ref: main
           token: ${{ secrets.GH_ACCESS_TOKEN }}
 
       # Check if the xts-candidate tag exists
       # the command git branch --contains xts-tag-commit | grep --quiet <default branch>
-      # will return an exit code of 1 if the tagged commit is not found on the develop
+      # will return an exit code of 1 if the tagged commit is not found on the main
       # branch.
       - name: Check for tags
         id: check-tags-exist
@@ -93,17 +93,17 @@ jobs:
             gh run cancel ${{ github.run_id }}
           fi
 
-          # Check if the tag exists on the develop branch
+          # Check if the tag exists on the main branch
           set +e
-          git branch --contains "${XTS_COMMIT}" | grep --quiet develop >/dev/null 2>&1
+          git branch --contains "${XTS_COMMIT}" | grep --quiet main >/dev/null 2>&1
           BRANCH_ON_DEVELOP="${?}"
           set -e
 
           # Get commit author
           AUTHOR_NAME=$(git log -1 --format='%an' "${XTS_COMMIT}")
           AUTHOR_EMAIL=$(git log -1 --format='%ae' "${XTS_COMMIT}")
 
-          # If the tag exists on the Develop Branch set the output variables as appropriate
+          # If the tag exists on the Main Branch set the output variables as appropriate
           # Otherwise cancel out
           if [[ "${BRANCH_ON_DEVELOP}" -eq 0 ]]; then
             echo "xts-tag-exists=true" >> $GITHUB_OUTPUT
@@ -260,7 +260,7 @@ jobs:
         uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
         with:
           fetch-depth: '0'
-          ref: develop
+          ref: main
           token: ${{ secrets.GH_ACCESS_TOKEN }}
 
       - name: Collect run logs in a log file

.github/workflows/zxcron-promote-build-candidate.yaml

@@ -52,7 +52,7 @@ jobs:
         uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
         with:
           fetch-depth: '0'
-          ref: develop
+          ref: main
           token: ${{ secrets.GH_ACCESS_TOKEN }}
 
       - name: Find Build Candidates
@@ -74,8 +74,8 @@ jobs:
               gh run cancel ${{ github.run_id }}
             fi
 
-            # Verify the commit is on develop and continue
-            if git branch --contains "${CANDIDATE_COMMIT}" | grep --quiet develop >/dev/null 2>&1; then
+            # Verify the commit is on main and continue
+            if git branch --contains "${CANDIDATE_COMMIT}" | grep --quiet main >/dev/null 2>&1; then
               git push --delete origin $(git tag --list "${TAG_PATTERN}")
               git tag --delete $(git tag --list "${TAG_PATTERN}")
               echo "build-candidate-exists=true" >> "${GITHUB_OUTPUT}"

.github/workflows/zxf-collect-workflow-logs.yaml

@@ -50,7 +50,7 @@ jobs:
         uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
         with:
           fetch-depth: '0'
-          ref: develop
+          ref: main
           token: ${{ secrets.GH_ACCESS_TOKEN }}
 
       - name: Get run logs

.github/workflows/zxf-prepare-extended-test-suite.yaml

@@ -50,18 +50,18 @@ jobs:
         uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
         with:
           fetch-depth: '0'
-          ref: 'develop'
+          ref: 'main'
           token: ${{ secrets.GH_ACCESS_TOKEN }}
 
       - name: Validate Input Ref
         id: validate-input
         env:
           COMMIT_ID: ${{ inputs.ref }}
         run: |
-          if git merge-base --is-ancestor "${COMMIT_ID}" develop >/dev/null 2>&1; then
+          if git merge-base --is-ancestor "${COMMIT_ID}" main >/dev/null 2>&1; then
             echo "commit_on_dev=true" >> $GITHUB_OUTPUT
           else
-            echo "::error title=Branch Alignment::The provided commit (${COMMIT_ID}) is not present on the develop branch."
+            echo "::error title=Branch Alignment::The provided commit (${COMMIT_ID}) is not present on the main branch."
             exit 1
           fi
 

docs/branch-naming-conventions.md

@@ -20,18 +20,19 @@ naming standard.
 
 ### Permanent & Default Branches
 
-The repository will contain two permanent branches as per the GitFlow Workflow `main` and `develop`
-branches.
+The repository will contain one permanent branch, `main`, per the Hashgraph Continuous Integration
+Test and Release workflow
 
 **Default Branches**
 
-The default branch for a repository will be `develop` as per the branching workflow.
+The default branch for a repository will be `main` as per the Hashgraph Continuous Integration
+Test and Release workflow.
 
 ### Branch to Issue Relationship
 
 Aside from the permanent or release branches, no short-lived (feature, hotfix, bugfix) branch should
 be created without being associated to an issue number. No short-lived branch should be merged into
-`develop` or `main` without an associated and approved pull request.
+`main` without an associated and approved pull request.
 
 ### Feature Branch Naming
 

docs/continuous-integration-testing-overview.md

@@ -20,11 +20,11 @@ two major components of CITR: MATS and XTS.
 MATS is the Minimal Acceptable Test Suite; this suite of tests is run against every pull request (PR) that is opened in
 the `hashgraph/hedera-services` repository.
 
-XTS is the eXtended Test Suite; this suite of tests is run against the latest commit on the develop branch every three
+XTS is the eXtended Test Suite; this suite of tests is run against the latest commit on the main branch every three
 hours (provided there is a new commit to run against).
 
 MATS tests are inclusive of a series of unit tests and performance tests that must be executed against a PR branch prior
-to merging into develop. The MATS tests are intended to complete within a 30-minute time window to provide developers
+to merging into main. The MATS tests are intended to complete within a 30-minute time window to provide developers
 with valuable insight of the impact of new code on the default branch.
 
 XTS tests are run against the default branch once every three hours. These cover test cases that are unable to complete
@@ -38,14 +38,14 @@ There is an additional workflow: `ZXF: Extended Test Suite - Dry Run` which is a
 `hashgraph/hedera-services` repository.
 
 The XTS Dry-Run workflow runs a provided commit on any branch through the same XTS tests that would be run against the
-latest on develop every three hours. This workflow is run with a manual trigger and will execute in parallel to any
+latest on main every three hours. This workflow is run with a manual trigger and will execute in parallel to any
 other actions ongoing in the `hashgraph/hedera-services` repository.
 
 A developer can manually trigger a run using the parameters in the web UI:
 
 ```text
 Use Workflow From
-  Branch: develop # this should always be `develop`
+  Branch: main # this should always be `main`
 The commit sha to check out
   <your current commit hash>
 The branch name, for JRS Panel output

docs/glossary.md

@@ -193,9 +193,9 @@ This file contains the address book to use when starting from genesis.
 **Congestion Pricing**: A mechanism designed to manage network congestion by dynamically adjusting
 transaction fees based on network demand. The primary goal of congestion pricing is to discourage
 excessive network usage during peak times. Refer to
-[Congestion Pricing](https://github.com/hashgraph/hedera-services/blob/develop/hedera-node/docs/fees/automated-congestion-pricing.md)
+[Congestion Pricing](https://github.com/hashgraph/hedera-services/blob/main/hedera-node/docs/fees/automated-congestion-pricing.md)
 and
-[Fees](https://github.com/hashgraph/hedera-services/blob/develop/hedera-node/docs/design/app/fees.md).
+[Fees](https://github.com/hashgraph/hedera-services/blob/main/hedera-node/docs/design/app/fees.md).
 
 ## Consensus Time
 

docs/maintainers-guide.md

@@ -58,12 +58,10 @@ pattern for the development life cycle.
 
 ![gitflow-branching-model](./assets/gitflow-branching-model.png)
 
-Note especially the roles of the `main` and `develop` branches:
+Note especially the roles of the `main` branch:
 
-- `develop` is the default branch, the target of active development, and should at all times
+- `main` is the default branch, the target of active development, and should at all times
   should be a viable candidate for the next release.
-- `main` is a tightly-controlled branch that release engineering uses for final tags deployed to
-  production.
 
 ### Creating issues on GitHub
 
@@ -92,35 +90,34 @@ with 0.30 milestone on it.
 
 ![labels-on-issue](./assets/labels-on-issue.png)
 
-### Release Engineering Responsibilities
+### DevOps-CI Responsibilities
 
-The release engineering team will handle the following:
+The DevOps-CI team will handle the following:
 
-- Create a release branch from `develop` branch at the end of first sprint in the release cycle
-- Will merge the release branch for current deploying release into `main`
 - Will provide automated release processes and coordinate release schedules
 - Will handle production releases
+- Note: no release branch will be created
 
 ### User Stories
 
 #### As a developer, I would like to create a branch to work on the feature for the upcoming release
 
-As per the development model, every developer should create a feature branch from `develop` branch
+As per the development model, every developer should create a feature branch from `main` branch
 for working on a change targeted for the current release. The created branch should follow
 [naming conventions](branch-naming-conventions.md).
 
-The `develop` branch should be up-to-date with all the features going into the next release.
+The `main` branch should be up-to-date with all the features going into the next release.
 
 #### As a developer, I would like to create a branch to work on the feature NOT targeted for upcoming release
 
-As per the development model, every developer should create a feature branch to work from `develop`
+As per the development model, every developer should create a feature branch to work from `main`
 branch. The created branch should follow [naming conventions](branch-naming-conventions.md). But,
-the feature branch should NOT be merged into `develop` until the decision is made if the feature is
+the feature branch should NOT be merged into `main` until the decision is made if the feature is
 going into upcoming release.
 
 #### As a developer, I would like to merge my feature branch or bug fix for the upcoming release
 
-Open a pull request (PR) from the feature branch to `develop` branch and add
+Open a pull request (PR) from the feature branch to `main` branch and add
 `hashgraph/hedera-services-team` as reviewers.
 
 Also add the following labels on the PR :
@@ -134,7 +131,7 @@ PR should be merged after an approving review and all the checks are passed.
 NOTE:
 
 1. Any feature that is not going into the upcoming release should stay in the feature branch and
-   should not be merged to `develop`.
+   should not be merged to `main`.
 2. Please use either the Gradle command line `./gradlew qualityGate` or the
    [Google Java Format IntelliJ Plugin](https://github.com/google/google-java-format#intellij-android-studio-and-other-jetbrains-ides)
    to format your code to avoid failing checks in CI pipeline.
@@ -146,14 +143,14 @@ Once the release branch is created, only bugfixes or hotfixes should be merged i
 To do that, create a `hotfix` from the `release` branch. The created branch should follow
 [naming conventions](branch-naming-conventions.md). Once the fix is in the branch, open a PR to the
 release branch. Once the fix is merged into `release` branch, it should be cherry-picked into the
-`develop` branch.
+`main` branch.
 
 #### As a developer, I would like to merge a bugfix/hotfix from the production code
 
 To fix a bug from one of the previous releases(production code), create a hotfix branch from `main`.
 Once the fix is in the branch, create a PR targeting to `main`. Once bugfix is merged into `main`and
 it should be cherry-picked back into the current `release` branch(if the release branch is still
-open), and also into `develop`.
+open).
 
 ### DCO Sign Off
 

hedera-node/docs/design/app/workflows.md

@@ -118,18 +118,18 @@ All the objects used while handling the transaction belong to one of the followi
 Examples include the `NodeInfo` and `WorkingStateAccessor`.
 - **UserTxnScope** - Objects that are created once for platform transaction.
 Examples include the `Configuration`, `RecordListBuilder` and `TokenContext`.
-Dagger provides all the objects that can be constructed in this scope [here](https://github.com/hashgraph/hedera-services/tree/develop/hedera-node/hedera-app/src/main/java/com/hedera/node/app/workflows/handle/flow/txn/modules)
-and [UserTxnComponent](https://github.com/hashgraph/hedera-services/blob/develop/hedera-node/hedera-app/src/main/java/com/hedera/node/app/workflows/handle/flow/txn/UserTransactionComponent.java)
+Dagger provides all the objects that can be constructed in this scope [here](https://github.com/hashgraph/hedera-services/tree/main/hedera-node/hedera-app/src/main/java/com/hedera/node/app/workflows/handle/flow/txn/modules)
+and [UserTxnComponent](https://github.com/hashgraph/hedera-services/blob/main/hedera-node/hedera-app/src/main/java/com/hedera/node/app/workflows/handle/flow/txn/UserTransactionComponent.java)
 takes all the inputs that are needed to execute the user transaction.
 - **UserDispatchScope** - Objects that are created once for each user transaction that will be dispatched.
 Examples include the `SingleTransactionRecordBuilder` for user transaction and `FeeContext`.
-Dagger provides all the objects that can be constructed in this scope in [UserDispatchModule](https://github.com/hashgraph/hedera-services/blob/develop/hedera-node/hedera-app/src/main/java/com/hedera/node/app/workflows/handle/flow/dispatch/user/modules/UserDispatchModule.java) and `UserDispatchComponent`.
-and [UserDispatchComponent](https://github.com/hashgraph/hedera-services/blob/develop/hedera-node/hedera-app/src/main/java/com/hedera/node/app/workflows/handle/flow/dispatch/user/UserDispatchComponent.java)
+Dagger provides all the objects that can be constructed in this scope in [UserDispatchModule](https://github.com/hashgraph/hedera-services/blob/main/hedera-node/hedera-app/src/main/java/com/hedera/node/app/workflows/handle/flow/dispatch/user/modules/UserDispatchModule.java) and `UserDispatchComponent`.
+and [UserDispatchComponent](https://github.com/hashgraph/hedera-services/blob/main/hedera-node/hedera-app/src/main/java/com/hedera/node/app/workflows/handle/flow/dispatch/user/UserDispatchComponent.java)
 takes all the inputs that are needed to create the user dispatch.
 - **ChildDispatchScope** - Objects that are created once for each child transaction dispatch.
 Examples include the `ReadableStoreFactory` and `ChildFeeContext`.
-Dagger provides all the objects that can be constructed in the [ChildDispatchModule](https://github.com/hashgraph/hedera-services/blob/develop/hedera-node/hedera-app/src/main/java/com/hedera/node/app/workflows/handle/flow/dispatch/child/modules/ChildDispatchModule.java)
-and [ChildDispatchComponent](https://github.com/hashgraph/hedera-services/blob/develop/hedera-node/hedera-app/src/main/java/com/hedera/node/app/workflows/handle/flow/dispatch/child/ChildDispatchComponent.java)
+Dagger provides all the objects that can be constructed in the [ChildDispatchModule](https://github.com/hashgraph/hedera-services/blob/main/hedera-node/hedera-app/src/main/java/com/hedera/node/app/workflows/handle/flow/dispatch/child/modules/ChildDispatchModule.java)
+and [ChildDispatchComponent](https://github.com/hashgraph/hedera-services/blob/main/hedera-node/hedera-app/src/main/java/com/hedera/node/app/workflows/handle/flow/dispatch/child/ChildDispatchComponent.java)
 takes all the inputs that are needed to create the child dispatch.
 
 #### HandleWorkflow overview:
@@ -169,7 +169,7 @@ The overall high level steps are as follows:
 
 The `DispatchProcessor.processDispatch` will be called for user and child dispatches. This avoids duplicating
 any logic between user and child transactions, since both are treated as dispatches.
-For the child transactions, when a service calls one of the [dispatchXXXTransaction](https://github.com/hashgraph/hedera-services/blob/develop/hedera-node/hedera-app/src/main/java/com/hedera/node/app/workflows/handle/flow/DispatchHandleContext.java#L459)
+For the child transactions, when a service calls one of the [dispatchXXXTransaction](https://github.com/hashgraph/hedera-services/blob/main/hedera-node/hedera-app/src/main/java/com/hedera/node/app/workflows/handle/flow/DispatchHandleContext.java#L459)
 methods in `DispatchHandleContext`, a new child dispatch is created and `DispatchProcessor.processDispatch` is called.
 
 1. **Error Validation:** Checks if there is any error by node or user by re-assessing preHandleResult. It validates the following: