No commits should be made to the Asterisk 1.0 branch.
Commits to the Asterisk 1.2 branch should only address security issues or regressions introduced by previous security fixes. For a security issue, the commit should be accompanied by an Asterisk Security Advisory and an immediate release. When a commit goes in to fix a regression, the previous security advisory that is related to the change that introduced the bug should get updated to indicate that there is an updated version of the fix. A release should be made immediately for these regression fixes, as well.
Commits to Asterisk 1.4 must be to address bugs only. No new features should be introduced into Asterisk 1.4 to reduce the number of changes to this established release series. The only exceptions to this rule are for cases where something that may be considered a feature is needed to address a bug or security issue.
After a 1.6.X release is published, it will be maintained until 1.6.[X + 3] is released. While a 1.6.X release branch is still maintained, it will receive only bug fixes. Periodic maintenance releases will be made and labeled as 1.6.X.Y. 1.6.X.Y releases should go through a release candidate test cycle before being published.
For now, all previous 1.6 release will be maintained for security issues. Once we have more 1.6 releases to deal with, this part of the policy will likely change.
For some history on the motivations for Asterisk 1.6 release management, see the first two sections of this mailing list post.
Asterisk trunk is used as the main development area for upcoming Asterisk 1.6 releases. Commits to Asterisk trunk are not limited. They can be bug fixes, new features, and architectural improvements. However, for larger sets of changes, developers should work with the Asterisk project leaders to schedule them for inclusion. Care is taken not to include too many invasive sets of changes for each new Asterisk 1.6 release.
No changes should go into Asterisk trunk that are not ready to go into a release. While the upcoming release will go through a beta and release candidate test cycle, code should not be in trunk until the code has been tested and reviewed such that there is reasonable belief that the code is ready to go.
Just about anything goes as far as commits to this area goes. However, developers should keep in mind that anything committed here, as well as anywhere else on Digium's SVN server, falls under the contributor license agreement.
In addition to each developer having their own space for working on projects, there is also a team/group folder where group development efforts take place.
Finally, in each developer folder, there is a folder called "private". This is where developers can create branches for working on things that they are not ready for the whole world to see.