Changes after renaming master branch

.github/workflows/ci.yaml

@@ -1,11 +1,11 @@
 name: CI
 
-# Triggers the workflow on push or pull request events but only for the master branch
+# Triggers the workflow on push or pull request events but only for the main branch
 on:
   push:
-    branches: [ master ]
+    branches: [ main ]
   pull_request:
-    branches: [ master ]
+    branches: [ main ]
 
 jobs:
   build-and-validate:

.github/workflows/release-typescript-models.yaml

@@ -4,7 +4,7 @@ name: types
 
 on:
   push:
-    branches: [ master ]
+    branches: [ main ]
 
 jobs:
   release-typescript-models:

docs/proposals/registry/registry-structure.md

@@ -1,7 +1,7 @@
 # Devfile Registry Structure
 This document outlines the structure of a Devfile Registry Repository that’s used as the basis for an OCI Devfile Registry, hosted on Kubernetes. It also outlines how individual files in each stack will get pushed up to the OCI registry.
 
-This design proposal is a follow up to [Devfile Registry Packaging](https://github.com/devfile/api/blob/master/docs/proposals/registry/devfile-packaging.md) and I recommend reading that first.
+This design proposal is a follow up to [Devfile Registry Packaging](https://github.com/devfile/api/blob/main/docs/proposals/registry/devfile-packaging.md) and I recommend reading that first.
 
 ## As-is Today
 Currently, the top-level structure of a devfile registry’s repository is unwritten, but it usually consists of a **devfiles** or **stacks** folder, and any associated files specific to that registry

docs/proposals/versioning-and-release.md

@@ -14,7 +14,7 @@ The Devfile Kubernetes API (defined in https://github.com/devfile/api/) is the s
 
 **How to Update?**
 
-   1) Add a new folder for the version in the [devfile/api](https://github.com/devfile/api/) repository under [pkg/apis/workspaces](https://github.com/devfile/api/tree/master/pkg/apis/workspaces). For example `pkg/apis/workspaces/v1` if bumping the K8S API version to `v1`.
+   1) Add a new folder for the version in the [devfile/api](https://github.com/devfile/api/) repository under [pkg/apis/workspaces](https://github.com/devfile/api/tree/main/pkg/apis/workspaces). For example `pkg/apis/workspaces/v1` if bumping the K8S API version to `v1`.
    2) Add a schema and version in the CRD manifests
    3) Go through the JSON schema update process outlined below to update the JSON schema version.
    4) Update the devworkspace operator and devfile library to consume the Go structs in the new K8S API version, as needed.
@@ -74,7 +74,7 @@ The following steps outline the steps done to release a new version of the Devfi
 
       v) A PR is opened to merge these changes into the release branch
 
-      vi) The schema version on the master branch is bumped and a PR is opened, provided the schema version passed in is **not** older than the master branch schema version. 
+      vi) The schema version on the main branch is bumped and a PR is opened, provided the schema version passed in is **not** older than the main branch schema version. 
 
    5) Once the release PR is approved and merged, the release engineer creates a new release on GitHub based off the release branch that was just created and includes the generated `devfile.json` as a release artifact. 
        - The tag `v{major}.{minor}.{bugfix}`, where the `{major}.{minor}.{bugfix}` corresponds to the devfile schema version, is used to enable the new version of the API to be pulled in as a Go module.

make-release.sh

@@ -67,9 +67,9 @@ checkoutToReleaseBranch() {
     echo "[INFO] $BRANCH exists."
     resetChanges $BRANCH
   else
-    echo "[INFO] $BRANCH does not exist. Will create a new one from master."
-    resetChanges master
-    git push origin master:$BRANCH
+    echo "[INFO] $BRANCH does not exist. Will create a new one from main."
+    resetChanges main
+    git push origin main:$BRANCH
   fi
   git checkout -B $SCHEMA_VERSION
 }
@@ -106,8 +106,8 @@ bumpVersion() {
   SCHEMA_VERSION=$MAJOR.$((MINOR+1)).0-alpha
 }
 
-updateVersionOnMaster() {
-  # Checkout to a PR branch based on master to make our changes in
+updateVersionOnMain() {
+  # Checkout to a PR branch based on main to make our changes in
   git checkout -b $SCHEMA_VERSION
 
   # Set the schema version to the new version (with -alpha appended) and build the schemas
@@ -116,7 +116,7 @@ updateVersionOnMaster() {
   commitChanges "chore(post-release): bump schema version to ${SCHEMA_VERSION}"
 }
 
-compareMasterVersion() {
+comparemainVersion() {
   # Parse the version passed in.
   IFS='.' read -a semver <<< "$SCHEMA_VERSION"
   MAJOR=${semver[0]}
@@ -147,17 +147,17 @@ run() {
   createReleaseBranch
   createPR "Release version ${SCHEMA_VERSION}"
 
-  # If needed, bump the schema version in master and open a PR against master
-  # Switch back to the master branch
-  BRANCH=master
+  # If needed, bump the schema version in main and open a PR against main
+  # Switch back to the main branch
+  BRANCH=main
   resetChanges $BRANCH
-  if compareMasterVersion; then
-    echo "[INFO] Updating schema version on master to ${SCHEMA_VERSION}"
+  if comparemainVersion; then
+    echo "[INFO] Updating schema version on main to ${SCHEMA_VERSION}"
     bumpVersion
-    updateVersionOnMaster
-    createPR "Bump schema version on master to ${SCHEMA_VERSION}"
+    updateVersionOnMain
+    createPR "Bump schema version on main to ${SCHEMA_VERSION}"
   else
-    echo "[WARN] The passed in schema version ${SCHEMA_VERSION} is less than the current version on master, so not updating the master branch version"
+    echo "[WARN] The passed in schema version ${SCHEMA_VERSION} is less than the current version on main, so not updating the main branch version"
     exit 
   fi
 }

samples/devfiles/sample-devfile.yaml

@@ -8,7 +8,7 @@ projects:
       remotes:
         origin: "https://github.com/devfile/api"
       checkoutFrom:
-        revision: "master"
+        revision: "main"
         remote: origin
 components:
   - name: editor