Django は、バージョン 1.0 から、API の安定性と前方互換性を保証しています。つまり、あなたが開発対象とした Django のコードは、将来のリリースでも正しく動作するということです。ただし、プロジェクトで使用している Django のバージョンを上げるときは、小さな修正が必要になることもあります。詳しくは、バージョンアップしようとしているバージョンの リリースノート の「後方互換性を壊す変更点」のセクションを読んでください。
\n現在の文脈では、stable とは次のことを意味します。
\nすべてのパブリック API (このドキュメントに書かれている全部です) は、基本的に移動や名称の変更が行われることがない。もし行われるとしても、後方互換性のためのエイリアスが必ず提供される。
もし新しい機能がこれらの API に追加されるなら (よくあることです)、すでに存在するメソッドの意味を変えたり、壊したりすることがない。別の言い方をすれば、"stable" とは必ずしも "complete" (完全) であることを意味するわけではない。
何からの理由により、一度 stable であると宣言された API を削除したり置き換えたりしなければならなくなった場合には、deprecated (廃止) であると明言され、最低でも2つのフィーチャーリリースの間は削除されずに残される。deprecated となったメソッドが呼び出されたときは、警告が出される。
\nDjango のバージョンナンバリングのスキームの仕組みや、特定の機能の廃止されるプロセスについて詳しく知りたければ、 公式リリース を読んでください。
\nこれらの API の後方互換性を壊すのは、バグやセキュリティホールを修正するのにやむを得ない場合だけです。
一般に、ドキュメントに書かれていることは、内部の仕組み の部分を除いて、すべて stable だと考えてもらって大丈夫です。
\n安定性と後方互換性の保証について、数点だけ例外があります。
\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.
\n特定の API は、次のような方法で、明示的に "internal" (内部実装) と明記されています。
\nドキュメントの中には内部実装を参照していたり、内部実装であると述べている箇所があります。もし、ドキュメントが「これは内部実装である」と述べている場合、その箇所は変更される場合があります。
先頭にアンダースコア( _ )が付いた関数、メソッド、およびその他のオブジェクトは、プライベートなものであることを示すPythonの標準的な方法です。 いずれかのメソッドが単一の _ で始まる場合、それは内部APIです。