Changes between Version 269 and Version 270 of WikiStart


Ignore:
Timestamp:
Sep 21, 2007, 7:02:15 PM (17 years ago)
Author:
korpios
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WikiStart

    v269 v270  
    2525 * [http://www.djangoproject.com/documentation/contributing/#reporting-security-issues How to report security issues].
    2626
    27 == Branches in development ==
     27== Branches ==
    2828Development 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.
    2929
    3030Branches 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!
    3131
    32  * [wiki:NewformsAdminBranch newforms-admin]: A refactoring of Django's admin site to use the [http://www.djangoproject.com/documentation/newforms/ newforms library] rather than automatic manipulators, allowing for additional customization of admin-site functionality.
    33  * [wiki:QuerysetRefactorBranch queryset-refactor]: A refactoring of the way queries are constructed in Django's database layer.
    34  * [wiki:ModelInheritance]: Write-up discussing how inheritance/subclassing of models should work. Currently this is not implemented in the development version of Django, so if you need model subclassing stick to one of the older stable releases or use workarounds like one-to-one relationships.
    35  * [wiki:SchemaEvolution]: This is a new feature, under development as a project for the 2006 Summer of Code.
    36  * [wiki: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).
    37  * [wiki: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.
    38  * [wiki:FullHistory]: A "full content history" implementation with compare, revert, etc. A SoC 2006 project.
    39  * [wiki: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.
    40  * [wiki:GeoDjango]: A branch for building GIS-enabled web applications.  Includes geometry-related fields and an interface for using Django's ORM with a spatial database (currently only PostGIS).
    41  * 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.
    42 
    43 We are discouraging the creation of new branches inside the Django repository in the future; 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 easy way to do this is via [http://www.selenic.com/mercurial/ Mercurial], a distributed version control system; Tom Tobin has set up a Mercurial repository mirroring Django's trunk at [http://hg.korpios.com/django.trunk].
    44 
     32See DjangoBranches for a list of more information, including a list of active branches.
    4533
    4634== Descriptions of major changes to the codebase ==
Back to Top