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」 (内部実装) と明記されています。

  • Some documentation refers to internals and mentions them as such. If the documentation says that something is internal, we reserve the right to change it.
  • 先頭にアンダースコア( _ )が付いた関数、メソッド、およびその他のオブジェクトは、プライベートなものであることを示すPythonの標準的な方法です。 いずれかのメソッドが単一の _ で始まる場合、それは内部APIです。