diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index ddf275410f..960bc557b3 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -19,8 +19,10 @@ -- [ ] 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 diff --git a/.github/workflows/analysis.yml b/.github/workflows/analysis.yml index 3fa62003ff..2ecbfaef8c 100644 --- a/.github/workflows/analysis.yml +++ b/.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: diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 2cb49a21ca..f076d1b87d 100644 --- a/.github/workflows/ci.yml +++ b/.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 diff --git a/.github/workflows/scorecard.yml b/.github/workflows/scorecard.yml index 89cccc35e6..3807a1d9df 100644 --- a/.github/workflows/scorecard.yml +++ b/.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' diff --git a/CMakeLists.txt b/CMakeLists.txt index 09e14e7a06..3be19dbd1e 100644 --- a/CMakeLists.txt +++ b/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 () diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 8f3197e7bc..fb8cfc78b5 100644 --- a/CONTRIBUTING.md +++ b/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 diff --git a/README.md b/README.md index 220a228cb8..8f6cea42fb 100644 --- a/README.md +++ b/README.md @@ -4,7 +4,7 @@

-[![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) diff --git a/RELEASING.md b/RELEASING.md index 1df82d3aff..1cfcae6a0e 100644 --- a/RELEASING.md +++ b/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) diff --git a/SECURITY.md b/SECURITY.md index 1ec4aa00fd..b567428626 100644 --- a/SECURITY.md +++ b/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. | diff --git a/src/cmake/compiler.cmake b/src/cmake/compiler.cmake index 33ced9fbe4..434541d0a8 100644 --- a/src/cmake/compiler.cmake +++ b/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") diff --git a/src/cmake/testing.cmake b/src/cmake/testing.cmake index bedf2faf48..e13ca296ef 100644 --- a/src/cmake/testing.cmake +++ b/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) diff --git a/src/doc/CHANGES-0.x.md b/src/doc/CHANGES-0.x.md index b93e879d00..0473d88c82 100644 --- a/src/doc/CHANGES-0.x.md +++ b/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) diff --git a/src/doc/CHANGES-1.x.md b/src/doc/CHANGES-1.x.md index 47bf5dee11..fe0ba26dbe 100644 --- a/src/doc/CHANGES-1.x.md +++ b/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 diff --git a/src/doc/index.rst b/src/doc/index.rst index b6d884caf1..54f81cc4e8 100644 --- a/src/doc/index.rst +++ b/src/doc/index.rst @@ -27,7 +27,7 @@ OpenImageIO |version| `Web site `_ / `GitHub repository `_ / `Developer mail list `_ / - `Apache 2.0 BSD License `_ + `Apache 2.0 License `_ ------------ diff --git a/src/include/OpenImageIO/oiioversion.h.in b/src/include/OpenImageIO/oiioversion.h.in index 696ca787db..072546e240 100644 --- a/src/include/OpenImageIO/oiioversion.h.in +++ b/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@ diff --git a/testsuite/TESTSUITE-README.md b/testsuite/TESTSUITE-README.md index 8bc45a0be0..e0fecd245a 100644 --- a/testsuite/TESTSUITE-README.md +++ b/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