|Version 2 (modified by adrian, 10 years ago) (diff)|
Django's branch policy
This page outlines how we use Subversion branches for Django development.
In general, most development should be confined to the trunk, and the trunk should be kept stable. People should be able to run production sites against the trunk at any time.
Thus, large architectural changes -- that is, changes too large to be encapsulated in a single patch, or changes that need multiple eyes on them -- will have branches dedicated to them. See, for example, the [source:django/branches/i18n i18n branch]. If you have a change of this nature that you'd like to work on, ask on the django-developers list for a branch to be created for you.
We will only branch entire copies of the Django tree, even if work is only happening on part of that tree. This makes it painless to switch to a branch.
Developers working on a branch should periodically merge changes from the trunk into the branch. Please merge at least once a week. Every time you merge from the trunk, note the merge and revision numbers in the commit message.
Once the branch is stable and ready to be merged into the trunk, alert the django-developers list.
After a branch has been merged, it should be considered "dead"; write access to it will be disabled, and old branches will be periodically "trimmed". To keep our SVN wrangling to a minimum, we won't be merging from a given branch into the trunk more than once.
To test a given branch, you can simply check out the entire branch. Or, if you've got a working directory you'd like to switch to use a branch, you can use...
svn switch http://code.djangoproject.com/svn/django/branches/<branch>/
...in the root of your Django sandbox.