Clearly mention release branch

pages/docs/dev-docs/release-strategy.md

@@ -44,7 +44,7 @@ The core library repository follows semantic versioning.
 
 We group together breaking changes and release a new breaking version as needed, but not more frequently than once every two years (aiming for longer). This aims to give time and motivation to users to adopt new versions, and spreads the effort of preparing a release over a longer period of time. There is no fixed schedule for major releases, and we take time to ensure that no further breaking changes are needed soon after.
 
-We aim for feature releases twice per year, so that new features can be continuously shipped to new users, but we again don't get overly burdened by the release process, and feature releases maintain their significance. We define a feature freeze date (date after which no new feature contributions can be merged) and a release date (date of merging to the main branch and tagging the release). Since most of the development happens in universities, we align these dates with the lecture-free periods between semesters in these universities:
+We aim for feature releases twice per year, so that new features can be continuously shipped to new users, but we again don't get overly burdened by the release process, and feature releases maintain their significance. We define a feature freeze date (date after which no new feature contributions can be merged to the release branch) and a release date (date of merging the release branch to the main branch and tagging the release). Since most of the development happens in universities, we align these dates with the lecture-free periods between semesters in these universities:
 
 - spring release: feature freeze on March 20 at 23:59 CET, release as soon as possible in April
 - fall release: feature freeze on September 20 at 23:59 CET, release as soon as possible in October