RELEASING.md

Releasing a New Version

For project maintainers.

The project currently uses three long-lived branches:

• main for releases in the active 4.x line.
• develop for ongoing 4.x development between releases.
• support/3 for long-term support releases in the 3.x line.

1. Before committing to a release...
   1. Check the issue queue for critical issues.
   2. Search the codebase for important @todo comments.
2. Create a release tag for the line you are releasing:
   1. Make sure your local long-lived branches are current with upstream.
   2. Choose a semantic version number (x.y.z).
   3. For a 4.x release, start the release from develop with Gitflow using git flow release start x.y.z.
   4. For a 4.x release, finish it with git flow release finish x.y.z, which updates main and develop.
   5. For a 3.x maintenance release, create the release tag directly from support/3 and push the updated support/3 branch.
   6. Push the release tag to GitHub along with the updated long-lived branch or branches for that release line.
3. If a fix applies to multiple supported lines, backport or forward-port it between support/3, develop, and main as appropriate before releasing.
4. Create a GitHub release.
   1. Set the tag version and release title both to the new version number.
   2. Use the changelog for the description.