mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-08-04 02:48:35 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

Fixed #8753: converted "new in ..." callouts to proper Sphinx "versionadded/versionchanged" directives. Thanks to Marc Fargas for all the heavy lifting here.

Browse source 
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8843 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Jacob Kaplan-Moss 2008-09-02 03:40:42 +00:00
parent c435975cc7
commit 64a9469127
47 changed files with 303 additions and 232 deletions
Download patch file Download diff file Expand all files Collapse all files

24
docs/internals/contributing.txt
View file

@ -572,28 +572,20 @@ Documentation changes come in two forms:
* New features -- Documentation of features that have been added to the
framework since the last release.
Our philosophy is that "general improvements" are something that *all* current
Django users should benefit from, including users of trunk *and* users of the
latest release. Hence, the documentation section on djangoproject.com points
people by default to the newest versions of the docs, because they have the
latest and greatest content. (In fact, the Web site pulls directly from the
Subversion repository, converting to HTML on the fly.)
But this decision to feature bleeding-edge documentation has one large caveat:
any documentation of *new* features will be seen by Django users who don't
necessarily have access to those features yet, because they're only using the
latest release. Thus, our policy is:
Our policy is:
**All documentation of new features should be written in a way that clearly
designates the features are only available in the Django development
version. Assume documentation readers are using the latest release, not the
development version.**
Our traditional way of marking new features is by prefacing the features'
documentation with: "New in Django development version." Changes aren't
*required* to include this exact text, but all documentation of new features
should include the phrase "development version," so we can find and remove
those phrases for the next release.
Our prefered way for marking new features is by prefacing the features'
documentation with: ".. versionadded:: X.Y", followed by an optional one line
comment and a mandatory blank line.
General improvements, or other changes to the APIs that should be emphasised
should use the ".. versionchanged:: X.Y" directive (with the same format as the
``versionadded`` mentioned above.
Guidelines for ReST files
-------------------------