Version 1 (modified by trac, 12 years ago) (diff)


NOTE: This document is not Twisted policy. At the moment, it is some guy's opinion.

Twisted's Branching Policy

Summary: Every major development task must have a ticket in the tracker and be developed in a branch. Branches must be reviewed before merging.

Fixing a bug, implementing a new feature and refactoring code are all development tasks.

Each task must start life as a ticket in the issue tracker.

To begin development, create a branch in Subversion (under /Twisted/branches/<username>/). Name the branch with the convention <short-description>--<issue number>--<branch number>. Omit the branch number for the first branch.

svn copy svn+ssh:// svn+ssh://

When the task is deemed complete, use the buildbot to test the branch on all of Twisted's supported platforms. If all the tests pass, it is time for the branch to be reviewed.

Find a reviewer and assign the ticket to him/her in the issue tracker. Also, mark the ticket as 'testing'. The reviewer will add his/her comments to the ticket and assign the task back to the original developer.

When the reviewer is satisfied, merge the branch into trunk.

Branch lifetimes should be short. If trunk moves very far from the branch, the branch should be "merged forward" to pick up bug fixes and feature enhancements which might be useful. Doing this also makes the final merge easier, by keeping conflicts small and bringing them to the developer's attention before they become unmanageable.

To merge forward:

svn copy svn+ssh:// svn+ssh://

Switch to the new branch (new-feature--1234--1), merge the old branch (new-feature--1234) and commit.


Based on and See issue1222.

-- JonathanLange