|Version 19 (modified by Boo, 8 years ago) (diff)|
Development of major new features for Django tends to take place in branches — copies of the main codebase focused on a particular feature. Using branches makes it easier to experiment with such sweeping changes without possibly breaking the trunk — the main line of development.
Branches may not be stable, but they offer a chance to test out bleeding-edge code before it hits the mainline. Give them a try, and remember to send feedback to the branch maintainers!
- SchemaEvolution: This is a new feature, under development as a project for the 2006 Summer of Code.
- RowLevelPermissions: Currently Django's permission system only works at the level of an entire model -- e.g., user "Bob" has access to add flatpages and edit users. This Summer of Code project will extend the permission system to be much more fine-grained, so permissions will be able to be assigned per object instead of per model (so, for example, user "Bob" could be given permission to edit only flatpage number 24 and user number 12, instead of all flatpages and all users).
- Generic relations: a "generic foreign key" feature is currently under development, but not yet completed. There is no support for it yet in the admin application, and it is probably unwise to attempt to use it in a production application.
- GenericAuthorization: A more flexible authorization system for Django. The new system should allow for ACL's, role-based systems, and Django's current model-level permissions.
- FullHistory: A "full content history" implementation with compare, revert, etc. A SoC 2006 project.
- TextIndexingAbstractionLayer: An abstraction layer for full-text indexing and search engines such as Lucene, Xapian, and Hyper Estraier. Also known as Merquery, this Summer of Code project will most likely be placed in contrib.search.
Creating New Branches
We are discouraging the creation of new branches inside Django's subversion repository. If you'd like to work on a major new contribution to Django, we encourage you to set up a new "branch" elsewhere and let the Django-developers mailing list know about it. One tactic is to use a distributed revision control system ("DRCS", or sometimes "DSCM", see Wikipedia's article on revision control); these systems allow you to create your own repository anywhere you'd like, and typically include tools to import from Subversion. Options here include Bazaar, Git, Mercurial, and SVK.
Please note that the information regarding branches in the Contributing document is out of date with regards to Django's branch creation policy.
Distributed version control mirrors
You can fetch it with:
bzr branch lp:django
There are several git repositories out there, some of which are used to develop patches that will come to SVN.
- Matthias Kestenholz has set up several git repositories for Django and for a selection of Django applications:
- Jacob Kaplan-Moss has also set up an experimental git mirror (django-developers post):
- Other people also published their repositories, in case you want to add them as remotes:
- [Preferred] Full Mercurial mirror hosted at dpaste.com, updated every fifteen minutes: http://hg.dpaste.com/django/
- SVN2HG Gateway of Django and Active branches, updated hourly: http://hgsvn.trbs.net/django/
- GeoDjango Mercurial: includes gis-newforms (a merge of the gis and newforms-admin branches), example code, and other geospatial goodies.