API の安定性

Django は、バージョン 1.0 から、API の安定性と前方互換性を保証しています。つまり、あなたが開発対象とした Django のコードは、将来のリリースでも正しく動作するということです。ただし、プロジェクトで使用している Django のバージョンを上げるときは、小さな修正が必要になることもあります。詳しくは、バージョンアップしようとしているバージョンの リリースノート の「後方互換性を壊す変更点」のセクションを読んでください。

"stable" とは?

現在の文脈では、stable とは次のことを意味します。

  • すべてのパブリック API (このドキュメントに書かれている全部です) は、基本的に移動や名称の変更が行われることがない。もし行われるとしても、後方互換性のためのエイリアスが必ず提供される。

  • もし新しい機能がこれらの API に追加されるなら (よくあることです)、すでに存在するメソッドの意味を変えたり、壊したりすることがない。別の言い方をすれば、"stable" とは必ずしも "complete" (完全) であることを意味するわけではない。

  • 何からの理由により、一度 stable であると宣言された API を削除したり置き換えたりしなければならなくなった場合には、deprecated (廃止) であると明言され、最低でも2つのフィーチャーリリースの間は削除されずに残される。deprecated となったメソッドが呼び出されたときは、警告が出される。

    Django のバージョンナンバリングのスキームの仕組みや、特定の機能の廃止されるプロセスについて詳しく知りたければ、 公式リリース を読んでください。

  • これらの API の後方互換性を壊すのは、バグやセキュリティホールを修正するのにやむを得ない場合だけです。

stable な API

一般に、ドキュメントに書かれていることは、内部の仕組み の部分を除いて、すべて stable だと考えてもらって大丈夫です。

例外

安定性と後方互換性の保証について、数点だけ例外があります。

セキュリティ上の修正

If we become aware of a security problem -- hopefully by someone following our security reporting policy -- we'll do everything necessary to fix it. This might mean breaking backwards compatibility; security trumps the compatibility guarantee.

internal と記された API

特定の API は、次のような方法で、明示的に "internal" (内部実装) と明記されています。

  • ドキュメントの中には内部実装を参照していたり、内部実装であると述べている箇所があります。もし、ドキュメントが「これは内部実装である」と述べている場合、その箇所は変更される場合があります。
  • 先頭にアンダースコア( _ )が付いた関数、メソッド、およびその他のオブジェクトは、プライベートなものであることを示すPythonの標準的な方法です。 いずれかのメソッドが単一の _ で始まる場合、それは内部APIです。
Back to Top