Inclusive naming proposal (issue: #12110, Orlin Vasiliev) (#12383)

* Inclusive naming proposal (issue: #12110, Orlin Vasiliev) Basic renaming from 'master' to 'main' as primary branch according to https://github.com/cncf/foundation/blob/main/code-of-conduct.md#our-standards Signed-off-by: Andrea Benini <andreabenini@gmail.com> Signed-off-by: Derek Nola <derek.nola@suse.com> * Additional replacement of master with main in E2E testing, Github Action workflows Signed-off-by: Derek Nola <derek.nola@suse.com> --------- Signed-off-by: Andrea Benini <andreabenini@gmail.com> Signed-off-by: Derek Nola <derek.nola@suse.com> Co-authored-by: Derek Nola <derek.nola@suse.com>
2025-12-18 23:06:14 -05:00 · 2025-09-24 17:52:28 +02:00 · 2025-09-24 17:52:28 +02:00 · ade82387f7
commit ade82387f7
parent 1e45f1de72
53 changed files with 91 additions and 91 deletions
--- a/.drone.yml
+++ b/.drone.yml
@ -44,7 +44,7 @@ steps:
      - drone-publish.k3s.io
    ref:
      include:
-        - "refs/heads/master"
+        - "refs/heads/main"
        - "refs/heads/release-*"
    event:
      - push
@ -64,7 +64,7 @@ steps:
    instance:
    - drone-publish.k3s.io
    ref:
-    - refs/head/master
+    - refs/head/main
    - refs/tags/*
    event:
    - tag
@ -182,7 +182,7 @@ steps:
    instance:
    - drone-publish.k3s.io
    ref:
-    - refs/head/master
+    - refs/head/main
    - refs/tags/*
    event:
    - tag
@ -230,7 +230,7 @@ steps:
 - name: skipfiles
  image: plugins/git
  commands:
-  - export NAME=$(test $DRONE_BUILD_EVENT = pull_request && echo remotes/origin/${DRONE_COMMIT_BRANCH:-master} || echo ${DRONE_COMMIT_SHA}~)
+  - export NAME=$(test $DRONE_BUILD_EVENT = pull_request && echo remotes/origin/${DRONE_COMMIT_BRANCH:-main} || echo ${DRONE_COMMIT_SHA}~)
  - export DIFF=$(git --no-pager diff --name-only $NAME | grep -v -f .droneignore);
  - if [ -z "$DIFF" ]; then
        echo "All files in PR are on ignore list";
@ -276,7 +276,7 @@ steps:
    instance:
    - drone-publish.k3s.io
    ref:
-    - refs/head/master
+    - refs/head/main
    - refs/tags/*
    event:
    - tag
@ -317,7 +317,7 @@ steps:
 - name: skipfiles
  image: plugins/git
  commands:
-  - export NAME=$(test $DRONE_BUILD_EVENT = pull_request && echo remotes/origin/${DRONE_COMMIT_BRANCH:-master} || echo ${DRONE_COMMIT_SHA}~)
+  - export NAME=$(test $DRONE_BUILD_EVENT = pull_request && echo remotes/origin/${DRONE_COMMIT_BRANCH:-main} || echo ${DRONE_COMMIT_SHA}~)
  - export DIFF=$(git --no-pager diff --name-only $NAME | grep -v -f .droneignore);
  - if [ -z "$DIFF" ]; then
        echo "All files in PR are on ignore list";
@ -349,7 +349,7 @@ trigger:
  instance:
  - drone-publish.k3s.io
  ref:
-  - refs/head/master
+  - refs/head/main
  - refs/tags/*
  event:
    include:
@ -377,7 +377,7 @@ steps:
 - name: skipfiles
  image: plugins/git
  commands:
-  - export NAME=$(test $DRONE_BUILD_EVENT = pull_request && echo remotes/origin/${DRONE_COMMIT_BRANCH:-master} || echo ${DRONE_COMMIT_SHA}~)
+  - export NAME=$(test $DRONE_BUILD_EVENT = pull_request && echo remotes/origin/${DRONE_COMMIT_BRANCH:-main} || echo ${DRONE_COMMIT_SHA}~)
  - export DIFF=$(git --no-pager diff --name-only $NAME | grep -v -f .droneignore);
  - if [ -z "$DIFF" ]; then
        echo "All files in PR are on ignore list";
@ -409,7 +409,7 @@ trigger:
  instance:
    - drone-publish.k3s.io
  ref:
-    - refs/head/master
+    - refs/head/main
    - refs/tags/*
  event:
    - tag
@ -433,7 +433,7 @@ steps:
 - name: skipfiles
  image: plugins/git
  commands:
-  - export NAME=$(test $DRONE_BUILD_EVENT = pull_request && echo remotes/origin/${DRONE_COMMIT_BRANCH:-master} || echo ${DRONE_COMMIT_SHA}~)
+  - export NAME=$(test $DRONE_BUILD_EVENT = pull_request && echo remotes/origin/${DRONE_COMMIT_BRANCH:-main} || echo ${DRONE_COMMIT_SHA}~)
  - export DIFF=$(git --no-pager diff --name-only $NAME | grep -v -f .droneignore);
  - if [ -z "$DIFF" ]; then
        echo "All files in PR are on ignore list";
@ -539,7 +539,7 @@ steps:
    if [ "$DRONE_BUILD_EVENT" = "pull_request" ]; then
      cd tests/e2e/upgradecluster
      # Convert release-1.XX branch to v1.XX channel
-      if [ "$DRONE_BRANCH" = "master" ]; then
+      if [ "$DRONE_BRANCH" = "main" ]; then
        UPGRADE_CHANNEL="latest"
      else
        UPGRADE_CHANNEL=$(echo $DRONE_BRANCH | sed 's/release-/v/')
--- a/.github/PULL_REQUEST_TEMPLATE.md
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@ -1,5 +1,5 @@
 <!-- HTML Comments can be left in place or removed. -->
-<!-- Please see our contributing guide at https://github.com/k3s-io/k3s/blob/master/CONTRIBUTING.md for guidance on opening pull requests -->
+<!-- Please see our contributing guide at https://github.com/k3s-io/k3s/blob/main/CONTRIBUTING.md for guidance on opening pull requests -->

 #### Proposed Changes ####

@ -16,7 +16,7 @@
 #### Testing ####

 <!-- Is this change covered by testing? If not, consider adding a Unit or Integration test. -->
-<!-- See https://github.com/k3s-io/k3s/blob/master/tests/TESTING.md for more info -->
+<!-- See https://github.com/k3s-io/k3s/blob/main/tests/TESTING.md for more info -->

 #### Linked Issues ####

--- a/.github/actions/setup-go/action.yaml
+++ b/.github/actions/setup-go/action.yaml
@ -1,15 +1,15 @@
-name: 'Setup golang with master only caching'
-description: 'A composite action that installs golang, but with a caching strategy that only updates the cache on master branch.'
+name: 'Setup golang with main only caching'
+description: 'A composite action that installs golang, but with a caching strategy that only updates the cache on main branch.'
 runs:
  using: 'composite'
  steps:
    - uses: actions/setup-go@v5
      with:
        go-version-file: 'go.mod'  # Just use whatever version is in the go.mod file
-        cache: ${{ github.ref == 'refs/heads/master' || github.ref == 'refs/heads/release-1.32' }}
+        cache: ${{ github.ref == 'refs/heads/main' || github.ref == 'refs/heads/release-1.32' }}

    - name: Prepare for go cache
-      if: github.ref != 'refs/heads/master' && github.ref != 'refs/heads/release-1.32'
+      if: github.ref != 'refs/heads/main' && github.ref != 'refs/heads/release-1.32'
      shell: bash
      run: |
        echo "GO_CACHE=$(go env GOCACHE)" | tee -a "$GITHUB_ENV"
@ -17,7 +17,7 @@ runs:
        echo "GO_VERSION=$(go env GOVERSION | tr -d 'go')" | tee -a "$GITHUB_ENV"

    - name: Setup read-only cache
-      if: github.ref != 'refs/heads/master' && github.ref != 'refs/heads/release-1.32'
+      if: github.ref != 'refs/heads/main' && github.ref != 'refs/heads/release-1.32'
      uses: actions/cache/restore@v4
      with:
        path: |
--- a/.github/workflows/e2e.yaml
+++ b/.github/workflows/e2e.yaml
@ -61,14 +61,14 @@ jobs:
      - name: Set up vagrant and libvirt
        uses: ./.github/actions/vagrant-setup
      - name: Vagrant R/W Cache
-        if: matrix.etest != 'btrfs' && github.ref == 'refs/heads/master'
+        if: matrix.etest != 'btrfs' && github.ref == 'refs/heads/main'
        uses: actions/cache@v4
        with:
          path: |
             ~/.vagrant.d/boxes
          key: ${{ matrix.etest != 'btrfs' && 'vagrant-box-ubuntu-2404' || 'vagrant-box-leap' }}
      - name: Vagrant Read Cache
-        if: matrix.etest != 'btrfs' && github.ref != 'refs/heads/master'
+        if: matrix.etest != 'btrfs' && github.ref != 'refs/heads/main'
        uses: actions/cache/restore@v4
        with:
          path: |
--- a/.github/workflows/scorecard.yml
+++ b/.github/workflows/scorecard.yml
@ -12,7 +12,7 @@ on:
  schedule:
    - cron: '25 12 * * 5'
  push:
-    branches: [ "master" ]
+    branches: [ "main" ]

 # Declare default permissions as read only.
 permissions: read-all
--- a/.github/workflows/updatecli.yaml
+++ b/.github/workflows/updatecli.yaml
@ -17,7 +17,7 @@ jobs:
      contents: write
      issues: write
      pull-requests: write
-    if: github.ref == 'refs/heads/master'
+    if: github.ref == 'refs/heads/main'
    steps:
      - name: Checkout
        uses: actions/checkout@v5
--- a/GOVERNANCE.md
+++ b/GOVERNANCE.md
@ -38,7 +38,7 @@ K3s and its leadership embrace the following values:

 ## Maintainers

-K3s Maintainers have write access to the [project GitHub repository](https://github.com/k3s-io/k3s/). They can merge their own patches(after approval process) or patches from others. The current Maintainers can be found in [MAINTAINERS.md](https://github.com/k3s-io/k3s/blob/master/MAINTAINERS).  Maintainers collectively manage the project's resources and contributors.
+K3s Maintainers have write access to the [project GitHub repository](https://github.com/k3s-io/k3s/). They can merge their own patches(after approval process) or patches from others. The current Maintainers can be found in [MAINTAINERS.md](https://github.com/k3s-io/k3s/blob/main/MAINTAINERS).  Maintainers collectively manage the project's resources and contributors.

 This privilege carries specific responsibilities: Maintainers are people who care about the K3s project and want to help it grow and improve. A Maintainer is not just someone who can make changes, but someone who has demonstrated their ability to collaborate with the team, get the most knowledgeable people to review code and docs, contribute high-quality code, and follow through to fix issues (in code or tests).

@ -64,7 +64,7 @@ Anyone is eligible to become a Maintainer, you need to demonstrate a few or more
 * understanding of how the team works (policies, processes for testing and code review, etc),  
 * understanding of the project's code base and coding and documentation style.

-A new Maintainer must be proposed by an existing Maintainer by sending a message to the [developer mailing list](mailto:k3s-maintainers@lists.cncf.io) and opening PR in [MAINTAINERS](https://github.com/k3s-io/k3s/blob/master/MAINTAINERS). A [supermajority](#Supermajority) vote of existing Maintainers approves the application.  Maintainer nominations will be evaluated without prejudice to employer or demographics.
+A new Maintainer must be proposed by an existing Maintainer by sending a message to the [developer mailing list](mailto:k3s-maintainers@lists.cncf.io) and opening PR in [MAINTAINERS](https://github.com/k3s-io/k3s/blob/main/MAINTAINERS). A [supermajority](#Supermajority) vote of existing Maintainers approves the application.  Maintainer nominations will be evaluated without prejudice to employer or demographics.

 Maintainers who are selected will be granted the necessary GitHub rights, and invited to the [private Maintainer mailing list](mailto:k3s-maintainers@lists.cncf.io).

@ -179,15 +179,15 @@ If a vote does not meet quorum (e.g., fewer than 50% of Maintainers vote), the v

 ## Proposal Process(ADRs)

-One of the most important aspects in any open source community is the concept of proposals. Large changes to the codebase and/or new features should be preceded by a proposal in our repository [ADRs]([https://github.com/k3s-io/k3s/tree/master/docs/adrs](https://github.com/k3s-io/k3s/tree/master/docs/adrs)). This process allows for all members of the community to weigh in on the concept (including the technical details), share their comments and ideas, and offer to help. It also ensures that members are not duplicating work or inadvertently stepping on toes by making large conflicting changes.
+One of the most important aspects in any open source community is the concept of proposals. Large changes to the codebase and/or new features should be preceded by a proposal in our repository [ADRs](https://github.com/k3s-io/k3s/tree/main/docs/adrs). This process allows for all members of the community to weigh in on the concept (including the technical details), share their comments and ideas, and offer to help. It also ensures that members are not duplicating work or inadvertently stepping on toes by making large conflicting changes.

 The project roadmap is defined by accepted proposals.

 Proposals should cover the high-level objectives, use cases, and technical recommendations on how to implement. In general, the community member(s) interested in implementing the proposal should be either deeply engaged in the proposal process or be an author of the proposal.

-The proposal should be documented as a separate markdown file pushed [ADRs]([https://github.com/k3s-io/k3s/tree/master/docs/adrs](https://github.com/k3s-io/k3s/tree/master/docs/adrs)).directory in the [k3s](https://github.com/k3s-io/k3s/tree/master/docs/adrs) repository via PR. The name of the file should follow the name pattern `<short meaningful words joined by '-'>.md`, e.g: `clear-old-tags-with-policies.md`.
+The proposal should be documented as a separate markdown file pushed to the [ADRs directory](https://github.com/k3s-io/k3s/tree/main/docs/adrs) in the k3s repository via PR. The name of the file should follow the name pattern `<short meaningful words joined by '-'>.md`, e.g: `clear-old-tags-with-policies.md`.

-Use the [Proposal Template](https://github.com/k3s-io/k3s/tree/master/docs/adrs/template.md) as a starting point.(need to open PR for template)
+Use the [Proposal Template](https://github.com/k3s-io/k3s/tree/main/docs/adrs/template.md) as a starting point.(need to open PR for template)

 ### Proposal Lifecycle

@ -212,7 +212,7 @@ Smaller, self-contained changes (e.g., bug fixes, minor enhancements, or localiz

 Time zones permitting, Maintainers are expected to participate in the public developer meeting, which occurs [Community meetings](https://k3s.io/community/\#community-meetings)

-Maintainers will also have closed meetings in order to discuss security reports or [Code of Conduct](https://github.com/k3s-io/k3s/blob/master/CODE_OF_CONDUCT.md) violations.  Such meetings should be scheduled by any Maintainer on receipt of a security issue or CoC report.  All current Maintainers must be invited to such closed meetings, except for any Maintainer who is accused of a CoC violation.
+Maintainers will also have closed meetings in order to discuss security reports or [Code of Conduct](https://github.com/k3s-io/k3s/blob/main/CODE_OF_CONDUCT.md) violations.  Such meetings should be scheduled by any Maintainer on receipt of a security issue or CoC report.  All current Maintainers must be invited to such closed meetings, except for any Maintainer who is accused of a CoC violation.

 ## CNCF Resources

@ -220,7 +220,7 @@ Any Maintainer may suggest a request for CNCF resources, either in the [mailing

 ## Code of Conduct

-[Code of Conduct](https://github.com/k3s-io/k3s/blob/master/CODE_OF_CONDUCT.md) violations by community members will be discussed and resolved on the [private Maintainer mailing list](https://lists.cncf.io/g/cncf-k3s-maintainers).  If a Maintainer is directly involved in the report, the Maintainers will instead designate two Maintainers to work with the CNCF Code of Conduct Committee in resolving it.
+[Code of Conduct](https://github.com/k3s-io/k3s/blob/main/CODE_OF_CONDUCT.md) violations by community members will be discussed and resolved on the [private Maintainer mailing list](https://lists.cncf.io/g/cncf-k3s-maintainers).  If a Maintainer is directly involved in the report, the Maintainers will instead designate two Maintainers to work with the CNCF Code of Conduct Committee in resolving it.

 ## Security Response Team

--- a/ROADMAP.md
+++ b/ROADMAP.md
@ -4,4 +4,4 @@ The k3s project uses [GitHub Milestones](http://github.com/k3s-io/k3s/milestones

 The k3s release cycle moves in cadence with upstream Kubernetes, with an aim to have new minor releases out within 30 days of upstream .0 releases.  To follow incoming changes, watching the [Backlog](https://github.com/orgs/k3s-io/projects/5) and [Current Development](https://github.com/orgs/k3s-io/projects/6) GitHub Projects is the most up to date way to see what's coming in upcooming releases.

-The development of k3s itself happens in the `master` branch, which correlates to the most recent Kubernetes minor release.  These changes are then backported to the active release lines (at this time, `release-[N]`, `release-[N-1]`, and `release-[N-2]`)
+The development of k3s itself happens in the `main` branch, which correlates to the most recent Kubernetes minor release.  These changes are then backported to the active release lines (at this time, `release-[N]`, `release-[N-1]`, and `release-[N-2]`)
--- a/docs/adrs/add-dual-stack-support-to-netpol-agent.md
+++ b/docs/adrs/add-dual-stack-support-to-netpol-agent.md
@ -10,7 +10,7 @@ Accepted

 Currently the network policy agent included in k3s is in fact a copied code of
 [kube-router's](https://github.com/cloudnativelabs/kube-router) network policy
-controller, which can be found [here](https://github.com/k3s-io/k3s/tree/master/pkg/agent/netpol).
+controller, which can be found [here](https://github.com/k3s-io/k3s/tree/main/pkg/agent/netpol).

 The first and the most important issue is that kube-router lacks support for
 dual-stack (and even IPv6 in general in the most of its components). However,
--- a/docs/adrs/gh-branch-strategy.md
+++ b/docs/adrs/gh-branch-strategy.md
@ -8,14 +8,14 @@ Accepted

 ## Context

-K3s is released at the same cadence as upstream Kubernetes. This requires management of multiple versions at any given point in time. The current branching strategy uses `release-v[MAJOR].[MINOR]`, with the `master` branch corresponding to the highest version released based on [semver](https://semver.org/). Github's Tags are then used to cut releases, which are just point-in-time snapshots of the specified branch at a given point. As there is the potential for bugs and regressions to be on present on any given branch, this branching and release strategy requires a code freeze to QA the branch without new potentially breaking changes going in.
+K3s is released at the same cadence as upstream Kubernetes. This requires management of multiple versions at any given point in time. The current branching strategy uses `release-v[MAJOR].[MINOR]`, with the `main` branch corresponding to the highest version released based on [semver](https://semver.org/). Github's Tags are then used to cut releases, which are just point-in-time snapshots of the specified branch at a given point. As there is the potential for bugs and regressions to be on present on any given branch, this branching and release strategy requires a code freeze to QA the branch without new potentially breaking changes going in.

 ## Decision
-All code changes go into the `master` branch. We maintain branches for all current release versions in the format `release-v[MAJOR].[MINOR]`. When changes made in master are necessary in a release, they should be backported directly into the release branches. If ever there are changes required only in the release branches and not in master, such as when bumping the kubernetes version from upstream, those can be made directly into the release branches themselves.
+All code changes go into the `main` branch. We maintain branches for all current release versions in the format `release-v[MAJOR].[MINOR]`. When changes made in main are necessary in a release, they should be backported directly into the release branches. If ever there are changes required only in the release branches and not in main, such as when bumping the kubernetes version from upstream, those can be made directly into the release branches themselves.

 ## Consequences

 - Allows for constant development, with code freeze only relevant for the release branches.
 - This requires maintaining one additional branch than the current workflow, which also means one additional issue.
- Testing would be more constant from the master branch.
+- Testing would be more constant from the main branch.
 - Minor release captain will have to cut the new branch as soon as they bring in that new minor version.
--- a/docs/adrs/integrate-vpns.md
+++ b/docs/adrs/integrate-vpns.md
@ -13,7 +13,7 @@ There are kubernetes use cases which require a kubernetes cluster to be deployed
 	* Having a baremetal cluster that requires, only in certain periods, to be extended with hyperscalers VMs to cope out with the demand
 	* Require cluster to include nodes in different hyperscalers due to resiliency reasons or legal requirements, e.g. GDPR

-As of today, k3s allows to deploy a cluster on a set of heterogeneous nodes by a simple and robust solution. This is achieved by using the [websocket proxy](https://github.com/k3s-io/k3s/blob/master/pkg/agent/run.go#L277) to connect the control-plane of the cluster, i.e. kube-api <==> kubelet, and a vpn-type flannel backend, e.g. wireguard, to connect the data-plane, i.e. pod <==> pod/node.
+As of today, k3s allows to deploy a cluster on a set of heterogeneous nodes by a simple and robust solution. This is achieved by using the [websocket proxy](https://github.com/k3s-io/k3s/blob/main/pkg/agent/run.go#L277) to connect the control-plane of the cluster, i.e. kube-api <==> kubelet, and a vpn-type flannel backend, e.g. wireguard, to connect the data-plane, i.e. pod <==> pod/node.

 The current solution works well but has a few limitations:
 	* It requires the server to have a public IP
--- a/docs/adrs/remove-svclb-daemonset.md
+++ b/docs/adrs/remove-svclb-daemonset.md
@ -20,7 +20,7 @@ The loadbalancer controller takes care of three tasks:
 2 - Sets up the infrastructure to provide the connectivity (externalIP ==> service)
 3 - Sets the externalIP

-K3s embeds a simple [loadbalancer controller](https://github.com/k3s-io/k3s/tree/master/pkg/cloudprovider) that we call svclb, which has been part of K3s since its inception. When a new service of type LoadBalancer comes up, this svclb [creates a daemonset](https://github.com/k3s-io/k3s/blob/master/pkg/cloudprovider/loadbalancer.go#L35). That daemonset uses [hostPort](https://github.com/k3s-io/k3s/blob/master/pkg/cloudprovider/servicelb.go#L526-L531) to reserve the service port in all nodes. Subsequently, the serviceLB controller queries the daemonset pods [to know the node ips](https://github.com/k3s-io/k3s/blob/master/pkg/cloudprovider/servicelb.go#L291) and sets those node ips as [the externalIPs for the service](https://github.com/k3s-io/k3s/blob/master/pkg/cloudprovider/servicelb.go#L299)
+K3s embeds a simple [loadbalancer controller](https://github.com/k3s-io/k3s/tree/main/pkg/cloudprovider) that we call svclb, which has been part of K3s since its inception. When a new service of type LoadBalancer comes up, this svclb [creates a daemonset](https://github.com/k3s-io/k3s/blob/main/pkg/cloudprovider/loadbalancer.go#L35). That daemonset uses [hostPort](https://github.com/k3s-io/k3s/blob/main/pkg/cloudprovider/servicelb.go#L526-L531) to reserve the service port in all nodes. Subsequently, the serviceLB controller queries the daemonset pods [to know the node ips](https://github.com/k3s-io/k3s/blob/main/pkg/cloudprovider/servicelb.go#L291) and sets those node ips as [the externalIPs for the service](https://github.com/k3s-io/k3s/blob/main/pkg/cloudprovider/servicelb.go#L299)

 When an external client wants to reach the service, it needs to point to any of the node ips and use the service port. The flow of traffic would be the following:
 1 - Traffic reaches the node
--- a/docs/contrib/git_workflow.md
+++ b/docs/contrib/git_workflow.md
@ -20,7 +20,7 @@ K3s project uses the [GitHub flow](https://docs.github.com/en/get-started/quicks
 Every forked repository works independently, meaning that any contributor can create branches with the name they see fit. However, it is worth noting that K3s mirrors [Kubernetes version skew policy](https://kubernetes.io/releases/version-skew-policy/) by maintaining release branches for the most recent three minor releases. The only exception is that the main branch mirrors the latest Kubernetes release (1.23) instead of using a `release-` prefixed one.

 ```text
-master       -------------------------------------------. (Kubernetes 1.23)
+main         -------------------------------------------. (Kubernetes 1.23)
 release-1.21            \---------------|---------------. (Kubernetes 1.21)
 release-1.22                            \---------------. (Kubernetes 1.22)
 ```
@ -74,23 +74,23 @@ Every time one wants to work on a new K3s feature, we do:
 In code it would look this way:

 ```sh
-## Get local master up to date
+## Get local main up to date
 # Assuming the k3s clone is the current working directory
 git fetch upstream
-git checkout master
-git rebase upstream/master
+git checkout main
+git rebase upstream/main

-## Create a new branch from master
+## Create a new branch from main
 git checkout -b myfeature
 ```

 ### Keeping local branches in sync

-Either when branching out from master or a release one, keep in mind it is worth checking if any change has been pushed upstream by doing:
+Either when branching out from main or a release one, keep in mind it is worth checking if any change has been pushed upstream by doing:

 ```sh
 git fetch upstream
-git rebase upstream/master
+git rebase upstream/main
 ```

 It is suggested to `fetch` then `rebase` instead of `pull` since the latter does a merge, which leaves merge commits. For this, one can consider changing the local repository configuration by doing `git config branch.autoSetupRebase always` to change the behavior of `git pull`, or another non-merge option such as `git pull --rebase`.
--- a/docs/release/expanded/channel_server.md
+++ b/docs/release/expanded/channel_server.md
@ -2,7 +2,7 @@

 Once the release is verified, the channel server config needs to be updated to reflect the new version for “stable”.  

-1. Channel.yaml can be found at the [root of the K3s repo.](https://github.com/k3s-io/k3s/blob/master/channel.yaml)
+1. Channel.yaml can be found at the [root of the K3s repo.](https://github.com/k3s-io/k3s/blob/main/channel.yaml)
   1. When updating the channel server a single-line change will need to be performed.  
   1. Release Captains responsible for this change will need to update the following stanza to reflect the new stable version of kubernetes relative to the release in progress.  
   1. Example:
--- a/docs/release/expanded/cut_release.md
+++ b/docs/release/expanded/cut_release.md
@ -4,7 +4,7 @@
 1. After the merge CI has completed, cut an RC by creating a release in the GitHub interface
   1. the title is the version of k3s you are releasing with the rc1 subversion eg. "v1.25.0-rc1+k3s1"
   1. In the case of a update to k3s, it should be incremented from `k3s1` to `k3s2`, for example, meaning the k3s version is being incremented.
-   1. the target should match the release branch, remember that the latest version is attached to "master"
+   1. the target should match the release branch, remember that the latest version is attached to "main"
   1. no description
   1. the tag should match the title
 1. After the RC is cut validate that the CI for the RC passes
--- a/docs/release/expanded/release_notes.md
+++ b/docs/release/expanded/release_notes.md
@ -40,7 +40,7 @@
      - if the commit is not in the comparison, try comparing the previous release tags
        - example: `https://github.com/k3s-io/k3s/compare/v1.25.0+k3s1...v1.25.2+k3s1`
        - the commit's merge issue should be listed in the release notes
-   1. if you are adding backports, make sure you are using the backport issues, not the one for master
+   1. if you are adding backports, make sure you are using the backport issues, not the one for main
 1. Verify component release versions
   - the list of components is completely static, someone should say something in the PR if we need to add to the list
     - Kubernetes, Kine, SQLite, Etcd, Containerd, Runc, Flannel, Metrics-server, Traefik, CoreDNS, Helm-controller, Local-path-provisioner
@ -65,7 +65,7 @@
       the build script runs 'make' on whatever was downloaded
       see https://github.com/k3s-io/k3s/blob/v1.23.13-rc2%2Bk3s1/scripts/version.sh#L40
       and https://github.com/k3s-io/k3s/blob/v1.23.13-rc2+k3s1/scripts/download#L29
-       and https://github.com/k3s-io/k3s/blob/master/scripts/build#L138
+       and https://github.com/k3s-io/k3s/blob/main/scripts/build#L138
     flannel: version.sh sets an env variable based on go.mod, then the build script builds it
       see https://github.com/k3s-io/k3s/blob/v1.23.13-rc2+k3s1/go.mod#L83
     metrics-server: version is set in the manifest at manifests/metric-server
--- a/docs/release/kubernetes-upgrade.md
+++ b/docs/release/kubernetes-upgrade.md
@ -190,7 +190,7 @@ git push --set-upstream origin ${NEW_K3S_VER}
 Create a commit with all the changes, and push this upstream.
 Create a PR to merge your branch into the corresponding release branch, and wait for CI to run tests on the PR. Make sure to create the PR against the associated release branch for this update.

-Once CI passes and you receive two approvals, you may now squash-merge the PR and then tag an RC after the merge to master CI run completes.
+Once CI passes and you receive two approvals, you may now squash-merge the PR and then tag an RC after the merge to main CI run completes.

 # Create a Release Candidate 
 Releases are kicked off and created by tagging a new tag.
@ -295,7 +295,7 @@ The resulting CI/CD run can be viewed here:
 [k3s-io/k3s Drone Dashboard](https://drone-publish.k3s.io/k3s-io/k3s)

 # Update Channel Server
-Once the release is verified, the channel server config needs to be updated to reflect the new version for “stable”. [channel.yaml can be found at the root of the K3s repo.](https://github.com/k3s-io/k3s/blob/master/channel.yaml)
+Once the release is verified, the channel server config needs to be updated to reflect the new version for “stable”. [channel.yaml can be found at the root of the K3s repo.](https://github.com/k3s-io/k3s/blob/main/channel.yaml)

 When updating the channel server a single-line change will need to be performed.
 Release Captains responsible for this change will need to update the following stanza to reflect the new stable version of kubernetes relative to the release in progress.
--- a/tests/docker/skew/skew_test.go
+++ b/tests/docker/skew/skew_test.go
@ -30,7 +30,7 @@ func Test_DockerSkew(t *testing.T) {
 var lastMinorVersion string
 var _ = BeforeSuite(func() {
 	// If this test runs on v1.31 commit, we want the latest v1.30 release
-	// For master and unreleased branches, we want the latest stable release
+	// For main and unreleased branches, we want the latest stable release
 	var upgradeChannel string
 	var err error
 	// We want to substract one from the minor version to get the previous release
--- a/tests/e2e/btrfs/Vagrantfile
+++ b/tests/e2e/btrfs/Vagrantfile
@ -5,7 +5,7 @@ NODE_ROLES = (ENV['E2E_NODE_ROLES'] ||
  ["server-0"])
 NODE_BOXES = (ENV['E2E_NODE_BOXES'] ||
  ['opensuse/Leap-15.6.x86_64'])
-GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "master")
+GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "main")
 RELEASE_VERSION = (ENV['E2E_RELEASE_VERSION'] || "")
 NODE_CPUS = (ENV['E2E_NODE_CPUS'] || 2).to_i
 NODE_MEMORY = (ENV['E2E_NODE_MEMORY'] || 2048).to_i
--- a/tests/e2e/btrfs/btrfs_test.go
+++ b/tests/e2e/btrfs/btrfs_test.go
@ -15,7 +15,7 @@ var ci = flag.Bool("ci", false, "running on CI")
 var local = flag.Bool("local", false, "deploy a locally built K3s binary")

 // Environment Variables Info:
-// E2E_RELEASE_VERSION=v1.23.1+k3s2 or nil for latest commit from master
+// E2E_RELEASE_VERSION=v1.23.1+k3s2 or nil for latest commit from main

 func Test_E2EBtrfsSnapshot(t *testing.T) {
 	RegisterFailHandler(Fail)
--- a/tests/e2e/dualstack/Vagrantfile
+++ b/tests/e2e/dualstack/Vagrantfile
@ -3,7 +3,7 @@ NODE_ROLES = (ENV['E2E_NODE_ROLES'] ||
  ["server-0", "server-1", "server-2", "agent-0" ])
 NODE_BOXES = (ENV['E2E_NODE_BOXES'] ||
  ['bento/ubuntu-24.04', 'bento/ubuntu-24.04', 'bento/ubuntu-24.04', 'bento/ubuntu-24.04'])
-GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "master")
+GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "main")
 RELEASE_VERSION = (ENV['E2E_RELEASE_VERSION'] || "")
 GOCOVER = (ENV['E2E_GOCOVER'] || "")
 NODE_CPUS = (ENV['E2E_NODE_CPUS'] || 2).to_i
--- a/tests/e2e/embeddedmirror/Vagrantfile
+++ b/tests/e2e/embeddedmirror/Vagrantfile
@ -3,7 +3,7 @@ NODE_ROLES = (ENV['E2E_NODE_ROLES'] ||
  ["server-0", "agent-0"])
 NODE_BOXES = (ENV['E2E_NODE_BOXES'] ||
  ['bento/ubuntu-24.04', 'bento/ubuntu-24.04'])
-GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "master")
+GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "main")
 RELEASE_VERSION = (ENV['E2E_RELEASE_VERSION'] || "")
 GOCOVER = (ENV['E2E_GOCOVER'] || "")
 NODE_CPUS = (ENV['E2E_NODE_CPUS'] || 2).to_i
--- a/tests/e2e/embeddedmirror/embeddedmirror_test.go
+++ b/tests/e2e/embeddedmirror/embeddedmirror_test.go
@ -22,7 +22,7 @@ var ci = flag.Bool("ci", false, "running on CI")
 var local = flag.Bool("local", false, "deploy a locally built K3s binary")

 // Environment Variables Info:
-// E2E_RELEASE_VERSION=v1.23.1+k3s2 (default: latest commit from master)
+// E2E_RELEASE_VERSION=v1.23.1+k3s2 (default: latest commit from main)
 // E2E_REGISTRY: true/false (default: false)

 func Test_E2EEmbeddedMirror(t *testing.T) {
--- a/tests/e2e/externalip/Vagrantfile
+++ b/tests/e2e/externalip/Vagrantfile
@ -3,7 +3,7 @@ NODE_ROLES = (ENV['E2E_NODE_ROLES'] ||
  ["server-0", "agent-0" ])
 NODE_BOXES = (ENV['E2E_NODE_BOXES'] ||
  ['bento/ubuntu-24.04', 'bento/ubuntu-24.04'])
-GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "master")
+GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "main")
 RELEASE_VERSION = (ENV['E2E_RELEASE_VERSION'] || "")
 GOCOVER = (ENV['E2E_GOCOVER'] || "")
 NODE_CPUS = (ENV['E2E_NODE_CPUS'] || 2).to_i
--- a/tests/e2e/privateregistry/Vagrantfile
+++ b/tests/e2e/privateregistry/Vagrantfile
@ -3,7 +3,7 @@ NODE_ROLES = (ENV['E2E_NODE_ROLES'] ||
  ["server-0", "agent-0"])
 NODE_BOXES = (ENV['E2E_NODE_BOXES'] ||
  ['bento/ubuntu-24.04', 'bento/ubuntu-24.04', 'bento/ubuntu-24.04', 'bento/ubuntu-24.04', 'bento/ubuntu-24.04'])
-GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "master")
+GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "main")
 RELEASE_VERSION = (ENV['E2E_RELEASE_VERSION'] || "")
 GOCOVER = (ENV['E2E_GOCOVER'] || "")
 NODE_CPUS = (ENV['E2E_NODE_CPUS'] || 2).to_i
--- a/tests/e2e/privateregistry/privateregistry_test.go
+++ b/tests/e2e/privateregistry/privateregistry_test.go
@ -24,7 +24,7 @@ var ci = flag.Bool("ci", false, "running on CI")
 var local = flag.Bool("local", false, "deploy a locally built K3s binary")

 // Environment Variables Info:
-// E2E_RELEASE_VERSION=v1.23.1+k3s2 (default: latest commit from master)
+// E2E_RELEASE_VERSION=v1.23.1+k3s2 (default: latest commit from main)
 // E2E_REGISTRY: true/false (default: false)

 func Test_E2EPrivateRegistry(t *testing.T) {
--- a/tests/e2e/rootless/Vagrantfile
+++ b/tests/e2e/rootless/Vagrantfile
@ -1,7 +1,7 @@
 ENV['VAGRANT_NO_PARALLEL'] = 'no'
 NODE_ROLES = (ENV['E2E_NODE_ROLES'] ||  ["server-0"])
 NODE_BOXES = (ENV['E2E_NODE_BOXES'] ||  ['bento/ubuntu-24.04'])
-GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "master")
+GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "main")
 RELEASE_VERSION = (ENV['E2E_RELEASE_VERSION'] || "")
 GOCOVER = (ENV['E2E_GOCOVER'] || "")
 NODE_CPUS = (ENV['E2E_NODE_CPUS'] || 2).to_i
--- a/tests/e2e/rootless/rootless_test.go
+++ b/tests/e2e/rootless/rootless_test.go
@ -21,7 +21,7 @@ var ci = flag.Bool("ci", false, "running on CI")
 var local = flag.Bool("local", false, "deploy a locally built K3s binary")

 // Environment Variables Info:
-// E2E_RELEASE_VERSION=v1.27.1+k3s2 or nil for latest commit from master
+// E2E_RELEASE_VERSION=v1.27.1+k3s2 or nil for latest commit from main

 func Test_E2ERootless(t *testing.T) {
 	RegisterFailHandler(Fail)
--- a/tests/e2e/rotateca/Vagrantfile
+++ b/tests/e2e/rotateca/Vagrantfile
@ -3,7 +3,7 @@ NODE_ROLES = (ENV['E2E_NODE_ROLES'] ||
  ["server-0", "server-1", "server-2", "agent-0"])
 NODE_BOXES = (ENV['E2E_NODE_BOXES'] ||
  ['bento/ubuntu-24.04', 'bento/ubuntu-24.04', 'bento/ubuntu-24.04', 'bento/ubuntu-24.04'])
-GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "master")
+GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "main")
 RELEASE_VERSION = (ENV['E2E_RELEASE_VERSION'] || "")
 GOCOVER = (ENV['E2E_GOCOVER'] || "")
 NODE_CPUS = (ENV['E2E_NODE_CPUS'] || 2).to_i
--- a/tests/e2e/rotateca/rotateca_test.go
+++ b/tests/e2e/rotateca/rotateca_test.go
@ -19,7 +19,7 @@ var ci = flag.Bool("ci", false, "running on CI")
 var local = flag.Bool("local", false, "deploy a locally built K3s binary")

 // Environment Variables Info:
-// E2E_RELEASE_VERSION=v1.23.1+k3s2 or nil for latest commit from master
+// E2E_RELEASE_VERSION=v1.23.1+k3s2 or nil for latest commit from main

 func Test_E2ECustomCARotation(t *testing.T) {
 	RegisterFailHandler(Fail)
--- a/tests/e2e/s3/Vagrantfile
+++ b/tests/e2e/s3/Vagrantfile
@ -3,7 +3,7 @@ NODE_ROLES = (ENV['E2E_NODE_ROLES'] ||
  ["server-0"])
 NODE_BOXES = (ENV['E2E_NODE_BOXES'] ||
  ['bento/ubuntu-24.04'])
-GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "master")
+GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "main")
 RELEASE_VERSION = (ENV['E2E_RELEASE_VERSION'] || "")
 GOCOVER = (ENV['E2E_GOCOVER'] || "")
 NODE_CPUS = (ENV['E2E_NODE_CPUS'] || 2).to_i
--- a/tests/e2e/s3/s3_test.go
+++ b/tests/e2e/s3/s3_test.go
@ -22,7 +22,7 @@ var ci = flag.Bool("ci", false, "running on CI")
 var local = flag.Bool("local", false, "deploy a locally built K3s binary")

 // Environment Variables Info:
-// E2E_RELEASE_VERSION=v1.23.1+k3s2 (default: latest commit from master)
+// E2E_RELEASE_VERSION=v1.23.1+k3s2 (default: latest commit from main)
 // E2E_REGISTRY: true/false (default: false)

 func Test_E2ES3(t *testing.T) {
--- a/tests/e2e/scripts/Jenkinsfile
+++ b/tests/e2e/scripts/Jenkinsfile
@ -9,7 +9,7 @@ pipeline {
    stages {
        stage('Git Checkout') {
            steps {
-                    git branch: 'master', url: 'https://github.com/k3s-io/k3s.git'
+                    git branch: 'main', url: 'https://github.com/k3s-io/k3s.git'
                    script {
                        dir("${WORKSPACE}/tests/e2e") {
                        if (env.AWS_SSH_PEM_KEY && env.AWS_SSH_KEY_NAME) {
--- a/tests/e2e/scripts/run_tests.sh
+++ b/tests/e2e/scripts/run_tests.sh
@ -30,7 +30,7 @@ E2E_EXTERNAL_DB=$db && export E2E_EXTERNAL_DB
 E2E_REGISTRY=true && export E2E_REGISTRY

 cd
-cd k3s && git pull --rebase origin master
+cd k3s && git pull --rebase origin main
 /usr/local/go/bin/go mod tidy

 cd tests/e2e
@ -40,7 +40,7 @@ echo "$OS"
 vagrant global-status | awk '/running/'|cut -c1-7| xargs -r -d '\n' -n 1 -- vagrant destroy -f

 # To reduce GH API requsts, we grab the latest commit on the host and pass it to the tests
-./scripts/latest_commit.sh master latest_commit.txt
+./scripts/latest_commit.sh main latest_commit.txt
 E2E_RELEASE_VERSION=$(cat latest_commit.txt) && export E2E_RELEASE_VERSION

 echo 'RUNNING DUALSTACK TEST'
--- a/tests/e2e/scripts/setup_rootless.sh
+++ b/tests/e2e/scripts/setup_rootless.sh
@ -1,7 +1,7 @@
 #!/bin/sh

 # GitHub repository URL
-github_url="https://raw.githubusercontent.com/k3s-io/k3s/master/k3s-rootless.service"
+github_url="https://raw.githubusercontent.com/k3s-io/k3s/main/k3s-rootless.service"

 # Destination file path
 destination_path="/home/vagrant/.config/systemd/user/"
--- a/tests/e2e/secretsencryption/Vagrantfile
+++ b/tests/e2e/secretsencryption/Vagrantfile
@ -3,7 +3,7 @@ NODE_ROLES = (ENV['E2E_NODE_ROLES'] ||
  ["server-0", "server-1", "server-2"])
 NODE_BOXES = (ENV['E2E_NODE_BOXES'] ||
  ['bento/ubuntu-24.04', 'bento/ubuntu-24.04', 'bento/ubuntu-24.04'])
-GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "master")
+GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "main")
 RELEASE_VERSION = (ENV['E2E_RELEASE_VERSION'] || "")
 GOCOVER = (ENV['E2E_GOCOVER'] || "")
 NODE_CPUS = (ENV['E2E_NODE_CPUS'] || 2).to_i
--- a/tests/e2e/secretsencryption/secretsencryption_test.go
+++ b/tests/e2e/secretsencryption/secretsencryption_test.go
@ -22,7 +22,7 @@ var ci = flag.Bool("ci", false, "running on CI")
 var local = flag.Bool("local", false, "deploy a locally built K3s binary")

 // Environment Variables Info:
-// E2E_RELEASE_VERSION=v1.28.0+k3s1 or nil for latest commit from master
+// E2E_RELEASE_VERSION=v1.28.0+k3s1 or nil for latest commit from main

 func Test_E2ESecretsEncryption(t *testing.T) {
 	RegisterFailHandler(Fail)
--- a/tests/e2e/secretsencryption_old/Vagrantfile
+++ b/tests/e2e/secretsencryption_old/Vagrantfile
@ -3,7 +3,7 @@ NODE_ROLES = (ENV['E2E_NODE_ROLES'] ||
  ["server-0", "server-1", "server-2"])
 NODE_BOXES = (ENV['E2E_NODE_BOXES'] ||
  ['bento/ubuntu-24.04', 'bento/ubuntu-24.04', 'bento/ubuntu-24.04'])
-GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "master")
+GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "main")
 RELEASE_VERSION = (ENV['E2E_RELEASE_VERSION'] || "")
 GOCOVER = (ENV['E2E_GOCOVER'] || "")
 NODE_CPUS = (ENV['E2E_NODE_CPUS'] || 2).to_i
--- a/tests/e2e/secretsencryption_old/secretsencryption_test.go
+++ b/tests/e2e/secretsencryption_old/secretsencryption_test.go
@ -19,7 +19,7 @@ var ci = flag.Bool("ci", false, "running on CI")
 var local = flag.Bool("local", false, "deploy a locally built K3s binary")

 // Environment Variables Info:
-// E2E_RELEASE_VERSION=v1.23.1+k3s2 or nil for latest commit from master
+// E2E_RELEASE_VERSION=v1.23.1+k3s2 or nil for latest commit from main

 func Test_E2ESecretsEncryptionOld(t *testing.T) {
 	RegisterFailHandler(Fail)
--- a/tests/e2e/splitserver/Vagrantfile
+++ b/tests/e2e/splitserver/Vagrantfile
@ -3,7 +3,7 @@ NODE_ROLES = (ENV['E2E_NODE_ROLES'] ||
  ["server-etcd-0", "server-etcd-1", "server-etcd-2", "server-cp-0", "server-cp-1", "agent-0", "agent-1"])
 NODE_BOXES = (ENV['E2E_NODE_BOXES'] ||
  ['bento/ubuntu-24.04', 'bento/ubuntu-24.04', 'bento/ubuntu-24.04', 'bento/ubuntu-24.04', 'bento/ubuntu-24.04', 'bento/ubuntu-24.04', 'bento/ubuntu-24.04'])
-GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "master")
+GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "main")
 RELEASE_VERSION = (ENV['E2E_RELEASE_VERSION'] || "")
 GOCOVER = (ENV['E2E_GOCOVER'] || "")
 NODE_CPUS = (ENV['E2E_NODE_CPUS'] || 2).to_i
--- a/tests/e2e/splitserver/splitserver_test.go
+++ b/tests/e2e/splitserver/splitserver_test.go
@ -27,7 +27,7 @@ var local = flag.Bool("local", false, "deploy a locally built K3s binary")
 var hardened = flag.Bool("hardened", false, "true or false")

 // Environment Variables Info:
-// E2E_RELEASE_VERSION=v1.23.1+k3s2 or nil for latest commit from master
+// E2E_RELEASE_VERSION=v1.23.1+k3s2 or nil for latest commit from main

 // createSplitCluster creates a split server cluster with the given nodeOS, etcdCount, controlPlaneCount, and agentCount.
 // It duplicates and merges functionality found in the e2e.CreateCluster and e2e.CreateLocalCluster functions.
--- a/tests/e2e/startup/Vagrantfile
+++ b/tests/e2e/startup/Vagrantfile
@ -3,7 +3,7 @@ NODE_ROLES = (ENV['E2E_NODE_ROLES'] ||
  ["server-0", "agent-0"])
 NODE_BOXES = (ENV['E2E_NODE_BOXES'] ||
  ['bento/ubuntu-24.04', 'bento/ubuntu-24.04'])
-GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "master")
+GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "main")
 RELEASE_VERSION = (ENV['E2E_RELEASE_VERSION'] || "")
 GOCOVER = (ENV['E2E_GOCOVER'] || "")
 NODE_CPUS = (ENV['E2E_NODE_CPUS'] || 2).to_i
--- a/tests/e2e/startup/startup_test.go
+++ b/tests/e2e/startup/startup_test.go
@ -19,7 +19,7 @@ var ci = flag.Bool("ci", false, "running on CI")
 var local = flag.Bool("local", false, "deploy a locally built K3s binary")

 // Environment Variables Info:
-// E2E_RELEASE_VERSION=v1.23.1+k3s2 or nil for latest commit from master
+// E2E_RELEASE_VERSION=v1.23.1+k3s2 or nil for latest commit from main

 // This test suite is used to verify that K3s can start up with dynamic configurations that require
 // both server and agent nodes. It is unique in passing dynamic arguments to vagrant, unlike the
--- a/tests/e2e/tailscale/Vagrantfile
+++ b/tests/e2e/tailscale/Vagrantfile
@ -3,7 +3,7 @@ NODE_ROLES = (ENV['E2E_NODE_ROLES'] ||
  ["server-0", "agent-0", "agent-1" ])
 NODE_BOXES = (ENV['E2E_NODE_BOXES'] ||
  ['bento/ubuntu-24.04', 'bento/ubuntu-24.04', 'bento/ubuntu-24.04'])
-GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "master")
+GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "main")
 RELEASE_VERSION = (ENV['E2E_RELEASE_VERSION'] || "")
 GOCOVER = (ENV['E2E_GOCOVER'] || "")
 NODE_CPUS = (ENV['E2E_NODE_CPUS'] || 2).to_i
--- a/tests/e2e/upgradecluster/Vagrantfile
+++ b/tests/e2e/upgradecluster/Vagrantfile
@ -10,7 +10,7 @@ REGISTRY = (ENV['E2E_REGISTRY'] || "")
 GOCOVER = (ENV['E2E_GOCOVER'] || "")
 NODE_CPUS = (ENV['E2E_NODE_CPUS'] || 2).to_i
 NODE_MEMORY = (ENV['E2E_NODE_MEMORY'] || 2048).to_i
-GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "master")
+GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "main")
 # Virtualbox >= 6.1.28 require `/etc/vbox/network.conf` for expanded private networks 
 NETWORK_PREFIX = "10.10.11"
 install_type = ""
--- a/tests/e2e/upgradecluster/upgradecluster_test.go
+++ b/tests/e2e/upgradecluster/upgradecluster_test.go
@ -20,14 +20,14 @@ var serverCount = flag.Int("serverCount", 3, "number of server nodes")
 var agentCount = flag.Int("agentCount", 2, "number of agent nodes")
 var hardened = flag.Bool("hardened", false, "true or false")
 var ci = flag.Bool("ci", false, "running on CI")
-var local = flag.Bool("local", false, "Controls which version k3s upgrades too, local binary or latest commit on master")
+var local = flag.Bool("local", false, "Controls which version k3s upgrades too, local binary or latest commit on main")

 // Environment Variables Info:
 // E2E_REGISTRY: true/false (default: false)
 // Controls which K3s version is installed first
 // E2E_RELEASE_VERSION=v1.23.3+k3s1
 // OR
-// E2E_RELEASE_CHANNEL=(commit|latest|stable), commit pulls latest commit from master
+// E2E_RELEASE_CHANNEL=(commit|latest|stable), commit pulls latest commit from main

 func Test_E2EUpgradeValidation(t *testing.T) {
 	RegisterFailHandler(Fail)
--- a/tests/e2e/validatecluster/Vagrantfile
+++ b/tests/e2e/validatecluster/Vagrantfile
@ -3,7 +3,7 @@ NODE_ROLES = (ENV['E2E_NODE_ROLES'] ||
  ["server-0", "server-1", "server-2", "agent-0", "agent-1"])
 NODE_BOXES = (ENV['E2E_NODE_BOXES'] ||
  ['bento/ubuntu-24.04', 'bento/ubuntu-24.04', 'bento/ubuntu-24.04', 'bento/ubuntu-24.04', 'bento/ubuntu-24.04'])
-GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "master")
+GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "main")
 RELEASE_VERSION = (ENV['E2E_RELEASE_VERSION'] || "")
 EXTERNAL_DB = (ENV['E2E_EXTERNAL_DB'] || "etcd")
 HARDENED = (ENV['E2E_HARDENED'] || "")
--- a/tests/e2e/validatecluster/validatecluster_test.go
+++ b/tests/e2e/validatecluster/validatecluster_test.go
@ -27,7 +27,7 @@ var local = flag.Bool("local", false, "deploy a locally built K3s binary")

 // Environment Variables Info:
 // E2E_EXTERNAL_DB: mysql, postgres, etcd (default: etcd)
-// E2E_RELEASE_VERSION=v1.23.1+k3s2 (default: latest commit from master)
+// E2E_RELEASE_VERSION=v1.23.1+k3s2 (default: latest commit from main)
 // E2E_REGISTRY: true/false (default: false)

 func Test_E2EClusterValidation(t *testing.T) {
--- a/tests/e2e/wasm/Vagrantfile
+++ b/tests/e2e/wasm/Vagrantfile
@ -3,7 +3,7 @@ NODE_ROLES = (ENV['E2E_NODE_ROLES'] ||
  ["server-0"])
 NODE_BOXES = (ENV['E2E_NODE_BOXES'] ||
  ['bento/ubuntu-24.04'])
-GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "master")
+GITHUB_BRANCH = (ENV['E2E_GITHUB_BRANCH'] || "main")
 RELEASE_VERSION = (ENV['E2E_RELEASE_VERSION'] || "")
 GOCOVER = (ENV['E2E_GOCOVER'] || "")
 NODE_CPUS = (ENV['E2E_NODE_CPUS'] || 2).to_i
--- a/tests/integration/kubeflags/kubeflags_test.go
+++ b/tests/integration/kubeflags/kubeflags_test.go
@ -144,7 +144,7 @@ var _ = Describe("create a new cluster with kube-* flags", Ordered, func() {
 			})
 			/* The flag --disable-cloud-controller doesn't stop ccm from running,
 			it appends -cloud-node and -cloud-node-lifecycle to the end of the --controllers flag
-			https://github.com/k3s-io/k3s/blob/master/docs/adrs/servicelb-ccm.md
+			https://github.com/k3s-io/k3s/blob/main/docs/adrs/servicelb-ccm.md
 			*/
 			It("should find cloud-controller-manager starting with"+
 				"\"--cloud-node,--cloud-node-lifecycle,--secure-port=0\" flags ", func() {
--- a/tests/perf/README.md
+++ b/tests/perf/README.md
@ -2,7 +2,7 @@

 ---

-These scripts uses Terraform to automate building and testing on k3s clusters on AWS, it supports building normal and HA clusters with N master nodes, N workers nodes and multiple storage backends including:
+These scripts uses Terraform to automate building and testing on k3s clusters on AWS, it supports building normal and HA clusters with N primary nodes, N workers nodes and multiple storage backends including:

 - MySQL RDS
 - Postgres RDS
@ -17,7 +17,7 @@ The scripts divides into three sections:

 ## Server

-The server section deploys the storage backend and then deploys N master nodes, the scripts can be customized to use HA mode or use a single node cluster with sqlite backend, it can also support using 1 master node with external DB, the scripts can also be customized to specify instance type and k3s version, all available options are described in the variable section below.
+The server section deploys the storage backend and then deploys N primary nodes, the scripts can be customized to use HA mode or use a single node cluster with sqlite backend, it can also support using 1 primary node with external DB, the scripts can also be customized to specify instance type and k3s version, all available options are described in the variable section below.

 The server section will also create a one or more agent nodes specifically for Prometheus deployment, clusterloader2 will deploy prometheus and grafana.

@ -45,7 +45,7 @@ The scripts can be modified by customizing the variables in `scripts/config`, th
 |       Name       |                                   Description                                  |
 |:----------------:|:------------------------------------------------------------------------------:|
 |   CLUSTER_NAME   |     The cluster name on aws, this will prefix each component in the cluster    |
-|    DOMAIN_NAME   |                 DNS name of the Loadbalancer for k3s master(s)                 |
+|    DOMAIN_NAME   |                 DNS name of the Loadbalancer for k3s primary(s)                |
 |      ZONE_ID     |                 AWS route53 zone id for modifying the dns name                 |
 |    K3S_VERSION   |                 K3S version that will be used with the cluster                 |
 |  EXTRA_SSH_KEYS  |                Public ssh keys that will be added to the servers               |
@ -68,7 +68,7 @@ The scripts can be modified by customizing the variables in `scripts/config`, th
 |         Name         |                                    Description                                    |
 |:--------------------:|:---------------------------------------------------------------------------------:|
 |       SERVER_HA      | Whether or not to use HA mode, if not then sqlite will be used as storage backend |
-|     SERVER_COUNT     |                               k3s master node count                               |
+|     SERVER_COUNT     |                               k3s primary node count                              |
 | SERVER_INSTANCE_TYPE |                    Ec2 instance type created for k3s server(s)                    |

 ### K3S Agent Variables
@ -89,7 +89,7 @@ The scripts can be modified by customizing the variables in `scripts/config`, th

 ### build

-The script includes a Makefile that run different sections, to build the master and workers, adjust the config file in `tests/perf/scripts/config` and then use the following:
+The script includes a Makefile that run different sections, to build the primary and workers, adjust the config file in `tests/perf/scripts/config` and then use the following:

 ```bash
 cd tests/perf
--- a/tests/perf/server/variables.tf
+++ b/tests/perf/server/variables.tf
@ -71,7 +71,7 @@ variable "db_version" {}

 variable "server_count" {
  default     = 1
-  description = "Count of k3s master servers"
+  description = "Count of k3s primary servers"
 }

 variable "debug" {
--- a/updatecli/values.yaml
+++ b/updatecli/values.yaml
@ -6,7 +6,7 @@ github:
 k3s:
  org: "k3s-io"
  repo: "k3s"
-  branch: "master"
+  branch: "main"
 klipper_helm:
  org: "k3s-io"
  repo: "klipper-helm"