This page describes the process of making a release of OpenEXR and/or Imath.

Some important notes about the development process:

• All development happens in the master branch. PR's are merged into the master branch.

• OpenEXR enforces a linear commit history.  The GiHub repo allows squash merging and rebase merging but does not allow merge commits. 

• PR's are typically merged via "Squash and merge". This ensures that each PR ultimately corresponds to a single commit in the history. GitHub appends the PR number to the commit title upon squash, which makes this relationship easy to see: "Remove dead code in ImfB44Compressor.cpp (#1024)"

• Each major and minor release goes into a branch named "RB", e.g. RB-3.0. Each release is a tag starting with lowercase 'v', e.g. v3.0.4. Patch releases are tags along the corresponding RB- branch.

Major/Minor Release (e.g. v3.1.0)

This assumes that a new branch comes off of master.

• Create a branch off of master called RB-<major>.<minor>

• Follow the steps below for a Patch Release.

Patch Release (e.g. v3.0.4)

This assumes that changes on the master branch need to be merged into the release branch, e.g. RB-3.0.

1. Pick dates for feature freeze, code freeze, and release.

2. Create a v3.0.4 GitHub PR/Issue label

3. Add the label to PRs that should go into the release.

4. In your fork of the main repo, on branch RB-3.0, create v3.0.4-rc branch:
   % git checkout RB-3.0
% git pull
% git checkout b -v3.0.4 rc

5. Git cherry-pick appropriate commits from master branch. Since we "Squash and Merge" PR's on master, there should be a one-to-one correspondence between commits and PRs

6. Edit CHANGES.md and add release notes that summarize the changes. List the PRs with links. Submit as a separate commit so that this appears as a distinct entry in the commit history.

7. Bump the version in CMakeLists.txt.  Submit as a separate commit so that this appears as a distinct entry in the commit history.

8. Push the v3.0.4-rc branch and create a PR. Note this is into the RB-3.0 branch 

9. Wait for review. 

10. Merge the PR with "Rebase and Merge"

11. Create tag v3.0.4-rc1

12. Test. 

13.  

    1. Download and build. 

    2. Confirm fixes. 

    3. Confirm version number. 

    4. Run tests as standalone. 

14. Draft GitHub release. Use release notes from CHANGES.md. 

15. On the release date, publish the release. 

16. Update the "release" branch. In a clone of the main repo, check out the release branch and get merge v3.0.4. Git push. 

17. Send announcement to openexr-dev@lists.aswf.io

18. Merge the release notes into the master branch. In your fork:
    % git checkout master
% git merge upstream/master
% git checkout -b v3.0.4
% git cherry-pick release notes, any other changes 

19. Submit PR

20. Update website

21. Update master release version number.