admin: change docs and comments references master -> main

.github/PULL_REQUEST_TEMPLATE.md

@@ -19,8 +19,10 @@
 
 <!-- Put an 'x' in the boxes as you complete the checklist items -->
 
-- [ ] I have read the [contribution guidelines](https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/master/CONTRIBUTING.md).
-- [ ] I have updated the documentation, if applicable.
+- [ ] I have read the [contribution guidelines](https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/main/CONTRIBUTING.md).
+- [ ] I have updated the documentation, if applicable. (Check if there is no
+  need to update the documentation, for example if this is a bug fix that
+  doesn't change the API.)
 - [ ] I have ensured that the change is tested somewhere in the testsuite
   (adding new test cases if necessary).
 - [ ] If I added or modified a C++ API call, I have also amended the

.github/workflows/analysis.yml

@@ -11,9 +11,9 @@ on:
     # Run unconditionally once weekly
     # - cron: "0 0 * * 0"
   push:
-    # Run on pushes only to master or if the branch name contains "analysis"
+    # Run on pushes only to main or if the branch name contains "analysis"
     branches:
-      - master
+      - main
       - '*analysis*'
       - '*sonar*'
     paths-ignore:

.github/workflows/ci.yml

@@ -338,7 +338,7 @@ jobs:
                             WEBP_VERSION=v1.4.0
                             FREETYPE_VERSION=VER-2-13-3
                             USE_OPENVDB=0
-          - desc: bleeding edge gcc14 C++20 py3.12 OCIO/libtiff/exr-master avx2
+          - desc: bleeding edge gcc14 C++20 py3.12 OCIO/libtiff/exr-main avx2
             nametag: linux-bleeding-edge
             runner: ubuntu-24.04
             cc_compiler: gcc-14

.github/workflows/scorecard.yml

@@ -8,8 +8,8 @@ on:
   # Only the default branch is supported.
   branch_protection_rule:
   push:
-    # Run on pushes to master, but only the main repo, not forks
-    branches: [ "master" ]
+    # Run on pushes to main, but only the main repo, not forks
+    branches: [ "main" ]
     if: github.event.pull_request.head.repo.full_name == github.repository
     paths-ignore:
       - '**.md'

CMakeLists.txt

@@ -24,7 +24,7 @@ set (PROJECT_VERSION_RELEASE_TYPE "dev" CACHE STRING
 set (${PROJECT_NAME}_VERSION_RELEASE_TYPE ${PROJECT_VERSION_RELEASE_TYPE})
 set (PROJECT_AUTHORS "Contributors to the OpenImageIO project")
 option (${PROJECT_NAME}_SUPPORTED_RELEASE
-        "Set ON for supported release branch, OFF for master" OFF)
+        "Set ON for supported release branches, OFF for 'main'" OFF)
 if (${PROJECT_NAME}_SUPPORTED_RELEASE)
     set (${PROJECT_NAME}_DEV_RELEASE OFF)
 else ()

CONTRIBUTING.md

@@ -13,7 +13,7 @@ Contributing to OpenImageIO
 >
 
 Code contributions to OpenImageIO are always welcome, and [nearly 200
-people](https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/master/CREDITS.md) have done
+people](https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/main/CREDITS.md) have done
 so over the years.  Please review this document to get a briefing on our
 process.
 
@@ -87,13 +87,13 @@ safety, as it prevents any possible future disputes between code authors and
 their employers or anyone else who might think they might own the IP output of
 the author.
 
-* [Corporate CLA](https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/master/ASWF/CLA-corporate.md) :
+* [Corporate CLA](https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/main/ASWF/CLA-corporate.md) :
   If you are writing the code as part of your job, or if there is any
   possibility that your employers might think they own any intellectual
   property you create. This needs to be executed by someone who has
   signatory power for the company.
 
-* [Individual CLA](https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/master/ASWF/CLA-individual.md) :
+* [Individual CLA](https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/main/ASWF/CLA-individual.md) :
   If you are an individual writing the code on your own time, using your own
   equipment, and you're SURE you are the sole owner of any intellectual
   property you contribute.
@@ -265,7 +265,7 @@ of give and take. Please don't take it hard if your first try is not
 accepted. It happens to all of us.
 
 1. After approval, one of the senior developers (with commit approval to the
-official main repository) will merge your fixes into the master branch.
+official main repository) will merge your fixes into the main branch.
 
 
 Coding Style

README.md

@@ -4,7 +4,7 @@
   <img src="ASWF/logos/openimageio-horizontal-gradient.png">
 </p>
 
-[![License](https://img.shields.io/badge/license-Apache2.0-blue.svg?style=flat-square)](https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/master/LICENSE.md)
+[![License](https://img.shields.io/badge/license-Apache2.0-blue.svg?style=flat-square)](https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/main/LICENSE.md)
 [![CI](https://github.com/AcademySoftwareFoundation/OpenImageIO/actions/workflows/ci.yml/badge.svg)](https://github.com/AcademySoftwareFoundation/OpenImageIO/actions/workflows/ci.yml)
 [![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/2694/badge)](https://bestpractices.coreinfrastructure.org/projects/2694)
 [![latest packaged version(s)](https://repology.org/badge/latest-versions/openimageio.svg)](https://repology.org/project/openimageio/versions)

RELEASING.md

@@ -51,27 +51,27 @@ Tweak (fully forward and backward compatible) releases are not regularly
 scheduled, and only happen sporadically, when a critical fix is needed in
 between scheduled patch releases.
 
-### Things are different in "master"
+### Things are different in "main"
 
-The "master" branch is where ongoing development occurs without any
+The "main" branch is where ongoing development occurs without any
 compatibility guarantees. We don't always know if the next year's release from
-master will turn out to be major (API breaking) or minor (only ABI breaking).
+main will turn out to be major (API breaking) or minor (only ABI breaking).
 
 Some studios or products need the most up-to-date enhancements, and thus tend
-to build OIIO from the "master" branch rather than using tagged releases. For
-these users, we try to set version numbers and occasionally tag in master, to
-send a signal about which points in master seem safe to rely on various
+to build OIIO from the "main" branch rather than using tagged releases. For
+these users, we try to set version numbers and occasionally tag in main, to
+send a signal about which points in main seem safe to rely on various
 compatibility levels. However, the rules are slightly different than we use
 for releases.
 
-In the "master" branch:
+In the "main" branch:
 
-- TWEAK changes within "master" only guarantee ABI back-compatibility, but may
+- TWEAK changes within "main" only guarantee ABI back-compatibility, but may
   have additions or non-bug-fix behavior changes (akin to patch releases
   within a release branch).
-- PATCH changes within "master" are allowed to break ABI or API (changes that
-  would require minor or major releases, if they were not in "master").
-- Beware of unmarked breaks in compatibility of commits in master that are
+- PATCH changes within "main" are allowed to break ABI or API (changes that
+  would require minor or major releases, if they were not in "main").
+- Beware of unmarked breaks in compatibility of commits in main that are
   in between developer preview tags.
 
 
@@ -83,7 +83,7 @@ In the "master" branch:
 (and thus the branch markers will move over time). Branch names obey the
 following conventions:
 
-- `master` is the area for arbitrary changes intended for the next year's
+- `main` is the area for arbitrary changes intended for the next year's
   major or minor release.
 - `dev-1.2` are the areas for staging additions to the next month's patch
   release for the designated minor version series.
@@ -101,7 +101,7 @@ conventions:
 - `v1.2.3.4-alpha`, `v1.2.3.4-beta`, or `v1.2.3.4-RC1` are pre-releases for an
   upcoming public stable release, at the alpha, beta, or release candidate
   stages, respectively.
-- `v1.2.3.4-dev` is a "developer preview" within "master." It is not an official
+- `v1.2.3.4-dev` is a "developer preview" within "main." It is not an official
   supported release, and while the numbering may indicate compatibility versus
   other recent developer previews, they should not be assumed to be compatible
   with any prior official stable releases.
@@ -118,7 +118,7 @@ in general should be ignored by anyone who didn't make the tag or branch.
 ### Soft freeze for monthly tweak releases:
 
 We freely backport *safe*, non-ABI-breaking changes by cherry-picking them
-from master to the supported branch continually throughout most of the month.
+from main to the supported branch continually throughout most of the month.
 
 In the seven days before the new month, we do a "soft freeze" where only
 important bug fixes are backported. Hold on to any other patches you wish to
@@ -133,18 +133,18 @@ project during this soft freeze.
 By mid-June (about 1-2 months before the beta of a new annual big release),
 you should branch and mark it as an alpha.
 
-At the tip of "master", create a new branch named `dev-MAJOR.MINOR` that will
+At the tip of "main", create a new branch named `dev-MAJOR.MINOR` that will
 be the staging area for the next release.
 
-Customarily, at that point we add a commit to master (but not to the new
-dev-MAJ.MIN branch) that bumps master's version to the next minor level, to
-avoid any confusion between builds from master versus what will be the next
-release branch. This starts the divergence between master and the release
+Customarily, at that point we add a commit to main (but not to the new
+dev-MAJ.MIN branch) that bumps main's version to the next minor level, to
+avoid any confusion between builds from main versus what will be the next
+release branch. This starts the divergence between main and the release
 branch, and henceforth, any big or compatibility-breaking changes will only be
-committed to master and not backported to the release branch. (Though we are
+committed to main and not backported to the release branch. (Though we are
 loose about this rule during the alpha period and allow continued breaking
 changes in the alpha, but by the time we call it beta, we allow no more
-breaking changes.) Also at this stage, the master branch's CHANGES.md should
+breaking changes.) Also at this stage, the main branch's CHANGES.md should
 have a heading added at the top for the *next* version.
 
 
@@ -214,17 +214,17 @@ have a heading added at the top for the *next* version.
    - The `OpenImageIO_VERSION` should be correct.
    - The `PROJECT_VERSION_RELEASE_TYPE` variable should be set to "alpha" or
      "beta" if appropriate, "RC" for release candidate, or empty string `""`
-     for most supported releases, and "dev" only for the master branch or
+     for most supported releases, and "dev" only for the main branch or
      developer previews.
    - The `${PROJECT_NAME}_SUPPORTED_RELEASE` variable should be `ON` for any
-     release branch, `OFF` for master.
+     release branch, `OFF` for main.
 
 6. In the https://github.com/AcademySoftwareFoundation/OpenImageIO-images project, create a branch
    `dev-x.y` for the major/minor branch, and in the main oiio repo, update
    src/build-scripts/install_test_images.bash to specify `-b dev-x.y` in the
    checkout of oiio-images to ensure CI tests are against the set of test
    images corresponding to that major/minor release (just in the branch, not
-   in master!).
+   in main!).
 
 7. Make sure everything passes the usual CI workflow. Also check the daily or
    weekly "analysis" workflows to make sure there aren't any important
@@ -335,10 +335,10 @@ The following are the steps for making the release:
     > become less frequent and be reserved for only the most critical bug
     > fixes.
     > 
-    > The "master" branch is now progressing toward an eventual 3.1 release next
-    > fall. As usual, you are welcome to use master for real work, but we do
+    > The "main" branch is now progressing toward an eventual 3.1 release next
+    > fall. As usual, you are welcome to use main for real work, but we do
     > not make any compatibility guarantees and don't guarantee continuing API
-    > compatibility in master.
+    > compatibility in main.
     >
     > (Paste the full set of 3.0 changes here, just copy the appropriate
     > part of CHANGES.md)

SECURITY.md

@@ -7,7 +7,7 @@ security vulnerabilities.
 
 | Version / branch  | Supported                                            |
 | ----------------- | ---------------------------------------------------- |
-| master            | :white_check_mark: :construction: ALL fixes immediately, but this is a branch under development with a frequently unstable ABI and occasionally unstable API. |
+| main              | :white_check_mark: :construction: ALL fixes immediately, but this is a branch under development with a frequently unstable ABI and occasionally unstable API. |
 | 2.5.x             | :white_check_mark: All fixes that can be backported without breaking ABI compatibility. New tagged releases monthly. |
 | 2.4.x             | :warning: Only receives occasional critical fixes, upon request, only if they can be easily backported. |
 | <= 2.3.x          | :x: No longer receiving patches of any kind.        |

src/cmake/compiler.cmake

@@ -573,7 +573,7 @@ if (${PROJECT_NAME}_SUPPORTED_RELEASE)
     set (SOVERSION ${PROJECT_VERSION_MAJOR}.${PROJECT_VERSION_MINOR}
          CACHE STRING "Set the SO version for dynamic libraries")
 else ()
-    # Development master makes no ABI stability guarantee, so we make the
+    # Main development branch makes no ABI stability guarantee, so we make the
     # SO naming capture down to the major.minor.patch level.
     set (SOVERSION ${PROJECT_VERSION_MAJOR}.${PROJECT_VERSION_MINOR}.${PROJECT_VERSION_PATCH}
          CACHE STRING "Set the SO version for dynamic libraries")

src/cmake/testing.cmake

@@ -389,7 +389,7 @@ function (oiio_get_test_data name)
         # Test data directory didn't exist -- fetch it
         message (STATUS "Cloning ${name} from ${_ogtd_REPO}")
         if (NOT _ogtd_BRANCH)
-            set (_ogtd_BRANCH master)
+            set (_ogtd_BRANCH main)
         endif ()
         find_package (Git)
         if (Git_FOUND AND GIT_EXECUTABLE)

src/doc/CHANGES-0.x.md

@@ -1,6 +1,6 @@
 These are all the release notes for versions 0.1 (Sept 2008) - 0.10 (Feb 2012).
 For the full release notes of all versions, see:
-[CHANGES](https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/master/CHANGES.md).
+[CHANGES](https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/main/CHANGES.md).
 
 
 Release 0.10.5 (20 Feb 2012)

src/doc/CHANGES-1.x.md

@@ -1,7 +1,7 @@
 These are all the release notes for versions 1.0 (Feb 2012) - 1.8 (Dec 2018).
 For 0.x releases, see [CHANGES-0.x.md](CHANGES-0.x.md).
 For the full release notes of all versions, see:
-[CHANGES](https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/master/CHANGES.md).
+[CHANGES](https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/main/CHANGES.md).
 
 
 Release 1.8.17 (1 Dec 2018) -- compared to 1.8.16

src/doc/index.rst

@@ -27,7 +27,7 @@ OpenImageIO |version|
     `Web site <https://openimageio.org>`_ /
     `GitHub repository <https://github.com/AcademySoftwareFoundation/OpenImageIO>`_ /
     `Developer mail list <https://lists.aswf.io/g/oiio-dev>`_ /
-    `Apache 2.0 BSD License <https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/master/LICENSE.md>`_
+    `Apache 2.0 License <https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/main/LICENSE.md>`_
 
 
 ------------

src/include/OpenImageIO/oiioversion.h.in

@@ -39,7 +39,7 @@
 // prior release.
 //
 // Note that these designations only apply to released branches. Changes
-// in the main development branch ("master") do not make any compatibility
+// in the main development branch ("main") do not make any compatibility
 // guarantees at all.
 //
 #define OIIO_VERSION_MAJOR @PROJECT_VERSION_MAJOR@

testsuite/TESTSUITE-README.md

@@ -42,7 +42,7 @@ that allow just a teensy bit of low-bit errors in a few pixels. Sometimes, a
 failure is because it's slightly exceeding that. If so, you may be able to
 keep the existing reference output but just adjust the test to allow more
 slightly differing pixels. You can see how this is done
-[here](https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/master/testsuite/raw/run.py#L30),
+[here](https://github.com/AcademySoftwareFoundation/OpenImageIO/blob/main/testsuite/raw/run.py#L30),
 where we have raised the image matching threshold quite a bit because
 libraw's debayering seems to change a lot from version to version (making
 different, but usually perceptually indistinguishible outputs). Be gentle