Rename the default branch to "main"

Author: cbandy

.github/workflows/codeql-analysis.yaml

@@ -5,7 +5,6 @@ on:
   push:
     branches:
       - main
-      - master
   schedule:
     - cron: '10 18 * * 2'
 

.github/workflows/test.yaml

@@ -5,7 +5,6 @@ on:
   push:
     branches:
       - main
-      - master
 
 env:
   # Use the Go toolchain installed by setup-go

.github/workflows/trivy.yaml

@@ -5,7 +5,6 @@ on:
   push:
     branches:
       - main
-      - master
 
 env:
   # Use the Go toolchain installed by setup-go

CONTRIBUTING.md

@@ -13,15 +13,11 @@ Thanks! We look forward to your contribution.
 # General Contributing Guidelines
 
 All ongoing development for an upcoming release gets committed to the
-**`master`** branch. The `master` branch technically serves as the "development"
-branch as well, but all code that is committed to the `master` branch should be
+**`main`** branch. The `main` branch technically serves as the "development"
+branch as well, but all code that is committed to the `main` branch should be
 considered _stable_, even if it is part of an ongoing release cycle.
 
-All fixes for a supported release should be committed to the supported release
-branch. For example, the 4.3 release is maintained on the  `REL_4_3` branch.
-Please see the section on _Supported Releases_ for more information.
-
-Ensure any changes are clear and well-documented. When we say "well-documented":
+Ensure any changes are clear and well-documented:
 
 - If the changes include code, ensure all additional code has corresponding
 documentation in and around it. This includes documenting the definition of
@@ -32,10 +28,7 @@ summarize how. Avoid simply repeating details from declarations,. When in doubt,
 favor overexplaining to underexplaining.
 
 - Code comments should be consistent with their language conventions. For
-example, please use GoDoc conventions for Go source code.
-
-- Any new features must have corresponding user documentation. Any removed
-features must have their user documentation removed from the documents.
+example, please use `gofmt` [conventions](https://go.dev/doc/comment) for Go source code.
 
 - Do not submit commented-out code. If the code does not need to be used
 anymore, please remove it.
@@ -62,12 +55,7 @@ All commits must either be rebased in atomic order or squashed (if the squashed
 commit is considered atomic). Merge commits are not accepted. All conflicts must
 be resolved prior to pushing changes.
 
-**All pull requests should be made from the `master` branch** unless it is a fix
-for a specific supported release.
-
-Once a major or minor release is made, no new features are added into the
-release branch, only bug fixes. Any new features are added to the `master`
-branch until the time that said new features are released.
+**All pull requests should be made from the `main` branch.**
 
 # Commit Messages
 
@@ -90,8 +78,7 @@ If you wish to tag a GitHub issue or another project management tracker, please
 do so at the bottom of the commit message, and make it clearly labeled like so:
 
 ```
-Issue: #123
-Issue: [sc-1234]
+Issue: CrunchyData/postgres-operator#123
 ```
 
 # Submitting Pull Requests
@@ -100,102 +87,23 @@ All work should be made in your own repository fork. When you believe your work
 is ready to be committed, please follow the guidance below for creating a pull
 request.
 
-## Upcoming Releases / Features
-
-Ongoing work for new features should occur in branches off of the `master`
-branch. It is suggested, but not required, that the branch name should reflect
-that this is for an upcoming release, i.e. `upstream/branch-name` where the
-`branch-name` is something descriptive for what you're working on.
-
-## Supported Releases / Fixes
-
-While not required, it is recommended to make your branch name along the lines
-of: `REL_X_Y/branch-name` where the `branch-name` is something descriptive
-for what you're working on.
-
-# Releases & Versioning
-
-Overall, release tags attempt to follow the
-[semantic versioning](https://semver.org) scheme.
-
-"Supported releases" (described in the next section) occur on "minor" release
-branches (e.g. the `x.y` portion of the `x.y.z`).
-
-One or more "patch" releases can occur after a minor release. A patch release is
-used to fix bugs and other issues that may be found after a supported release.
-
-Fixes found on the `master` branch can be backported to a support release
-branch. Any fixes for a supported release must have a pull request off of the
-supported release branch, which is detailed below.
-
-## Supported Releases
+## Upcoming Features
 
-When a "minor" release is made, the release is stamped using the `vx.y.0` format
-as denoted above, and a branch is created with the name `REL_X_Y`. Once a
-minor release occurs, no new features are added to the `REL_X_Y` branch.
-However, bug fixes can (and if found, should) be added to this branch.
+Ongoing work for new features should occur in branches off of the `main`
+branch.
 
-To contribute a bug fix to a supported release, please make a pull request off
-of the supported release branch. For instance, if you find a bug in the 4.3
-release, then you would make a pull request off of the `REL_4_3` branch.
+## Unsupported Branches
 
-## Unsupported Releases
-
-When a release is no longer supported, the branch will be renamed following the
+When a release branch is no longer supported, it will be renamed following the
 pattern `REL_X_Y_FINAL` with the key suffix being _FINAL_. For example,
 `REL_3_2_FINAL` indicates that the 3.2 release is no longer supported.
 
 Nothing should ever be pushed to a `REL_X_Y_FINAL` branch once `FINAL` is on
 the branch name.
 
-## Alpha, Beta, Release Candidate Releases
-
-At any point in the release cycle for a new release, there could exist one or
-more alpha, beta, or release candidate (RC) release. Alpha, beta, and release
-candidates **should not be used in production environments**.
-
-Alpha is the early stage of a release cycle and is typically made to test the
-mechanics of an upcoming release. These should be considered relatively
-unstable. The format for an alpha release tag is `v4.3.0-alpha.1`, which in this
-case indicates it is the first alpha release for 4.3.
-
-Beta occurs during the later stage of a release cycle. At this point, the
-release should be considered feature complete and the beta is used to
-distribute, test, and collect feedback on the upcoming release. The betas should
-be considered unstable, but as mentioned feature complete. The format for an
-beta release tag is `v4.3.0-beta.1`, which in this case indicates it is the
-first beta release for 4.3.
-
-Release candidates (RCs) occur just before a release. A release candidate should
-be considered stable, and is typically used for a final round of bug checking
-and testing. Multiple release candidates can occur in the event of serious bugs.
-The format for a release candidate tag is `v4.3.0-rc.1`, which in this
-case indicates it is the first release candidate for 4.3.
-
-**After a major or minor release, no alpha, beta, or release candidate releases
-are supported**. In fact, any newer release of an alpha, beta, or RC immediately
-deprecates any older alpha, beta or RC. (Naturally, a beta deprecates an alpha,
-and a RC deprecates a beta).
-
-If you are testing on an older alpha, beta or RC, bug reports will not be
-accepted. Please ensure you are testing on the latest version.
-
 # Testing
 
-We greatly appreciate any and all testing for the project. When testing, please
-be sure you do the following:
-
-- If testing against a release, ensure your tests are performed against the
-latest minor version (the last number in the release denotes the minor version,
-e.g. the "3" in the 4.3.3)
-- If testing against a pre-release (alpha, beta, RC), ensure your tests are
-performed against latest version
-- If testing against a development (`master`) or release (`REL_X_Y`) branch,
-ensure your tests are performed against the latest commit
-
-Please do not test against unsupported versions (e.g. any release that is marked
-final).
-
+We greatly appreciate any and all testing for the project.
 There are several ways to help with the testing effort:
 
 - Manual testing: testing particular features with a series of manual commands

README.md

@@ -185,22 +185,18 @@ In addition to the above, the geospatially enhanced PostgreSQL + PostGIS contain
 
 For more information about which versions of the PostgreSQL Operator include which components, please visit the [compatibility](https://access.crunchydata.com/documentation/postgres-operator/v5/references/components/) section of the documentation.
 
-## Supported Platforms
+## [Supported Platforms](https://access.crunchydata.com/documentation/postgres-operator/latest/overview/supported-platforms)
 
 PGO, the Postgres Operator from Crunchy Data, is tested on the following platforms:
 
-- Kubernetes v1.28 - v1.31
-- OpenShift v4.12 - v4.16
+- Kubernetes
+- OpenShift
 - Rancher
 - Google Kubernetes Engine (GKE), including Anthos
 - Amazon EKS
 - Microsoft AKS
 - VMware Tanzu
 
-This list only includes the platforms that the Postgres Operator is specifically
-tested on as part of the release process: PGO works on other Kubernetes
-distributions as well.
-
 # Contributing to the Project
 
 Want to contribute to the PostgreSQL Operator project? Great! We've put together
@@ -214,7 +210,7 @@ Once you are ready to submit a Pull Request, please ensure you do the following:
    that you have followed the commit message format, added testing where
    appropriate, documented your changes, etc.
 1. Open up a pull request based upon the guidelines. If you are adding a new
-   feature, please open up the pull request on the `master` branch.
+   feature, please open up the pull request on the `main` branch.
 1. Please be as descriptive in your pull request as possible. If you are
    referencing an issue, please be sure to include the issue in your pull request