Page History

...

All new development, whether new features or general improvements, should be integrated into the latest revision or the trunk. Once a new feature is implemented and integrated into the trunk it can then be decided which branches the new development should be applied to. There may be rare cases where a new development only applies to a particular branch but in general all new features go to the trunk first and disseminated from there. The important thing is that all changes go into the trunk first, then get merged into the release branch as needed, so no changes ever get dropped by mistake. New features or improvements should never originate from a branch.

Changes should be kept in sync at all times where possible and this is the responsbility of the developer. The fix for on JIRA should be set to where it has landed, not where it is targeted, particularly if there is a delay in merging. For example, if a change is committed only to trunk, the issue must either be closed with fix for "2.1", or kept open and commented as "committed to trunk revXXX, branch merge pending" with fix for set to "2.0.x". Ideally, the change is committed to the branch immediately so the issue can be closed with fix for "2.0.x" without the additional comment.

If issues closed on the trunk should go into the branch, the release manager or other developers may choose to reopen them with the new fix for, merge and commit then close on the new target version release manager. So developers can focus on improvements in the trunk and the burden of merging will be the task of the release manager. New features or improvements should never originate from a branchThe responsibility of merging changes from the trunk to the various branches is the responsbility of the release manager for the branch in question. To be clear if you are committing changes to trunk do not merge your changes into any of the release branches.

Releases

Creating a release branch

...