This describes the handling of Git branches in the Neos project, effective as of September 2022.
Default branches
- There is no
masterormainbranch in the Flow or Neos development collections or distributions. - Other repositories may still have a
mainormasterbranch. -
mastershould be renamed tomainwhenever possible
The default branch should be one for the latest released version. Usually “higher version” branch exists as a target for the next minor release (this is what in most projects is the main branch.)
If you think a repository has an incorrectly set default branch, please let us know!
Branch naming
- Every minor version has a corresponding branch, named
x.y - There may already be a branch for the next major version, named
x.0, even though that version has not been released. That is to allow work on breaking changes without affecting the feature branch(es) below.
Branch creation
- To create a new release branch, use the respective job in Jenkins.
- PR branches should be created in forks, not in the Neos org repositories.
Target branches for pull requests
- Pull requests for bugfixes must be made against the lowest affected branch still maintained. Which branch that is, can be checked on Release roadmap & process - Why Neos CMS? - Neos.io
- Feature pull requests must be made against the branch for the next minor version.
- Breaking changes must only go into the branch for the next major version.
If in doubt, read Release roadmap & process - Why Neos CMS? - Neos.io and ask either in #creating or on Slack.
Upmerging
We merge bugfixes in the lowest affected branch still maintained. Which branch that is, can be checked on Release roadmap & process - Why Neos CMS? - Neos.io
To make sure all fixes land in later branches, too, we regularly do upmerges. That means we merge the oldest branch in the following branch, repeating this until the latest branch is up to date.
