Merge pull request #61 from Nordix/update/main-branch-kashif

⚠️  Add main branch reference

CONTRIBUTING.md

@@ -2,7 +2,7 @@
 
 Metal3 projects are [Apache 2.0 licensed](LICENSE) and accept contributions via
 GitHub pull requests. Those guidelines are the same as the
-[Cluster API guidelines](https://github.com/kubernetes-sigs/cluster-api/blob/master/CONTRIBUTING.md)
+[Cluster API guidelines](https://github.com/kubernetes-sigs/cluster-api/blob/main/CONTRIBUTING.md)
 
 <!-- START doctoc generated TOC please keep comment here to allow auto update -->
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
@@ -60,17 +60,17 @@ mistakes](https://github.com/golang/go/wiki/CodeReviewComments) in your PRs.
 Cluster API maintains older versions through `release-X.Y` branches. We accept
 backports of bug fixes to the most recent
 release branch. For example, if the most recent branch is `release-0.2`, and the
-`master` branch is under active
-development for v0.3.0, a bug fix that merged to `master` that also affects
+`main` branch is under active
+development for v0.3.0, a bug fix that merged to `main` that also affects
 `v0.2.x` may be considered for backporting
 to `release-0.2`. We generally do not accept PRs against older release branches.
 
 ## Breaking Changes
 
-Breaking changes are generally allowed in the `master` branch, as this is the
+Breaking changes are generally allowed in the `main` branch, as this is the
 branch used to develop the next minor release of Cluster API.
 
-There may be times, however, when `master` is closed for breaking changes. This
+There may be times, however, when `main` is closed for breaking changes. This
 is likely to happen as we near the release of a new minor version.
 
 Breaking changes are not allowed in release branches, as these represent minor

Makefile

@@ -331,14 +331,9 @@ release-binary: $(RELEASE_DIR)
 
 .PHONY: release-staging
 release-staging: ## Builds and push container images to the staging bucket.
-	REGISTRY=$(STAGING_REGISTRY) $(MAKE) docker-build-all docker-push-all release-tag-latest
+	REGISTRY=$(STAGING_REGISTRY) $(MAKE) docker-build-all docker-push-all
 
 
-.PHONY: release-tag-latest
-release-tag-latest: ## Adds the latest tag to the last build tag.
-	## TODO(vincepri): Only do this when we're on master.
-	gcloud container images add-tag $(CONTROLLER_IMG):$(TAG) $(CONTROLLER_IMG):latest
-
 .PHONY: release-notes
 release-notes: $(RELEASE_NOTES)  ## Generates a release notes template to be used with a release.
 	$(RELEASE_NOTES)

VERSIONING.md

@@ -1,15 +1,15 @@
 # Versioning
 
 Those guidelines are coming from
-[Cluster API](https://github.com/kubernetes-sigs/cluster-api/blob/master/VERSIONING.md)
+[Cluster API](https://github.com/kubernetes-sigs/cluster-api/blob/main/VERSIONING.md)
 as we try to follow closely the release process
 
 <!-- markdownlint-disable -->
 ## TL;DR:
 <!-- markdownlint-restore -->
 
 - We follow [Semantic Versioning (semver)](https://semver.org/).
-- The _master_ branch is where development happens, this might include breaking
+- The _main_ branch is where development happens, this might include breaking
   changes.
 - The _release-X_ branches contain stable, backward compatible code. A new
   _release-X_ branch is created at every major (X) release.
@@ -33,7 +33,7 @@ but essentially, for any given release X.Y.Z:
 changes.
 
 These guarantees extend to all code exposed in public APIs of
-Cluster API Provider Metal3. This includes code both in Cluster API Provider
+IP Address Manager. This includes code both in IP Address Manager
 Baremetal itself, *plus types from dependencies in public APIs*.  Types and
 functions not in public APIs are not considered part of the guarantee.
 
@@ -42,11 +42,11 @@ that we follow.
 
 ## Branches
 
-Cluster API Provider Metal3 contains two types of branches: the *master*
+IP Address Manager contains two types of branches: the *main*
 branch and *release-X* branches.
 
-The *master* branch is where development happens.  All the latest and
-greatest code, including breaking changes, happen on master.
+The *main* branch is where development happens.  All the latest and
+greatest code, including breaking changes, happen on main.
 
 The *release-X* branches contain stable, backwards compatible code.  Every
 major (X) release, a new such branch is created.  It is from these
@@ -80,7 +80,7 @@ separately.
 
 ### Commands and Workflow
 
-Cluster API Provider Metal3 follows the standard Kubernetes workflow: any PR
+IP Address Manager follows the standard Kubernetes workflow: any PR
 needs `lgtm` and `approved` labels, PRs authors must have signed the CNCF CLA,
 and PRs must pass the tests before being merged.  See [the contributor
 docs](https://github.com/kubernetes/community/blob/master/contributors/guide/pull-requests.md#the-testing-and-merge-workflow)
@@ -90,7 +90,7 @@ We use the same priority and kind labels as Kubernetes.  See the labels
 tab in GitHub for the full list.
 
 The standard Kubernetes comment commands should work in
-Cluster API Provider Metal3.  See [Prow](https://prow.k8s.io/command-help)
+IP Address Manager.  See [Prow](https://prow.k8s.io/command-help)
 for a command reference.
 
 ## Release Process
@@ -115,11 +115,11 @@ Refer to the [releasing document](./docs/releasing.md) for the exact steps.
 
 Try to avoid breaking changes.  They make life difficult for users, who
 have to rewrite their code when they eventually upgrade, and for
-maintainers/contributors, who have to deal with differences between master
+maintainers/contributors, who have to deal with differences between main
 and stable branches.
 
 That being said, we'll occasionally want to make breaking changes. They'll
-be merged onto master, and will then trigger a major release (see [Release
+be merged onto main, and will then trigger a major release (see [Release
 Process](#release-process)).  Because breaking changes induce a major
 revision, the maintainers may delay a particular breaking change until
 a later date when they are ready to make a major revision with a few
@@ -149,7 +149,7 @@ Development branches:
   changes (we still have to merge/manage multiple branches for development
   and stable)
 
-- can be confusing to contributors, who often expect master to have the
+- can be confusing to contributors, who often expect main to have the
   latest changes.
 
 ### Never break compatibility

config/default/manager_image_patch.yaml

@@ -8,5 +8,5 @@ spec:
     spec:
       containers:
       # Change the value of image field below to your controller image URL
-      - image: quay.io/metal3-io/ipam:master
+      - image: quay.io/metal3-io/ipam:main
         name: manager

docs/releasing.md

@@ -71,7 +71,7 @@ latest version.
 ### Update Metal3-dev-env
 
 Metal3-dev-env variables need to be modified. After a major or minor release,
-the new minor version should point to master for
+the new minor version should point to main for
 IPAM and the released version should point to the release branch.
 
 ### Update the image of IPAM in the release branch

examples/generate.sh

@@ -82,7 +82,7 @@ curl --fail -Ss -L -o "${COMPONENTS_CERT_MANAGER_GENERATED_FILE}" https://github
 echo "Downloaded ${COMPONENTS_CERT_MANAGER_GENERATED_FILE}"
 
 # Generate Cluster API provider components file.
-kustomize build "github.com/kubernetes-sigs/cluster-api/config/default/?ref=master" > "${COMPONENTS_CLUSTER_API_GENERATED_FILE}"
+kustomize build "github.com/kubernetes-sigs/cluster-api/config/default/?ref=main" > "${COMPONENTS_CLUSTER_API_GENERATED_FILE}"
 echo "Generated ${COMPONENTS_CLUSTER_API_GENERATED_FILE}"
 
 # Generate METAL3 Infrastructure Provider components file.