The release of Django 1.0 comes with a promise of API\nstability and forwards-compatibility. In a nutshell, this means that code you\ndevelop against a 1.X version of Django will continue to work with future\n1.X releases. You may need to make minor changes when upgrading the version of\nDjango your project uses: see the “Backwards incompatible changes” section of\nthe release note for the version or versions to which\nyou are upgrading.
\nIn this context, stable means:
\nAll the public APIs (everything in this documentation) will not be moved\nor renamed without providing backwards-compatible aliases.
If new features are added to these APIs – which is quite possible –\nthey will not break or change the meaning of existing methods. In other\nwords, “stable” does not (necessarily) mean “complete.”
If, for some reason, an API declared stable must be removed or replaced, it\nwill be declared deprecated but will remain in the API for at least two\nminor version releases. Warnings will be issued when the deprecated method\nis called.
\nSee Official releases for more details on how Django’s version\nnumbering scheme works, and how features will be deprecated.
\nWe’ll only break backwards compatibility of these APIs if a bug or\nsecurity hole makes it completely unavoidable.
In general, everything covered in the documentation – with the exception of\nanything in the internals area is considered stable.
\nThere are a few exceptions to this stability and backwards-compatibility\npromise.
\nIf we become aware of a security problem – hopefully by someone following our\nsecurity reporting policy – we’ll do\neverything necessary to fix it. This might mean breaking backwards\ncompatibility; security trumps the compatibility guarantee.
\nCertain APIs are explicitly marked as “internal” in a couple of ways:
\nSome documentation refers to internals and mentions them as such. If the\ndocumentation says that something is internal, we reserve the right to\nchange it.
Functions, methods, and other objects prefixed by a leading underscore\n(_). This is the standard Python way of indicating that something is\nprivate; if any method starts with a single _, it’s an internal API.