Django is committed to API stability and forwards-compatibility. In a nutshell,\nthis means that code you develop against a version of Django will continue to\nwork with future releases. You may need to make minor changes when upgrading\nthe version of Django your project uses: see the "Backwards incompatible\nchanges" section of the release note for the version\nor versions to which you are upgrading.
\nAt the same time as making API stability a very high priority, Django is also\ncommitted to continual improvement, along with aiming for "one way to do it"\n(eventually) in the APIs we provide. This means that when we discover clearly\nsuperior ways to do things, we will deprecate and eventually remove the old\nways. Our aim is to provide a modern, dependable web framework of the highest\nquality that encourages best practices in all projects that use it. By using\nincremental improvements, we try to avoid both stagnation and large breaking\nupgrades.
\nDaam konteks ini, stabil berarti:
\nSemua API umum (semuanya di dokumentasi ini) tidak akan dipindahkan atau dinamai kembali tanpa menyediakan alias belakang-sesuai.
Jika fitur baru ini ditambahkan ke API ini -- yang sangat memungkinkan -- mereka akan tidak rusak atau merubah arti dari metode yang ada. Dengan kata lain, "stabil" tidak (perlu) berarti "lengkap."
Jika, untuk beberapa alasan, sebuah API dinyatakan stabil harus dipindahkan atau diganti, dia akan dinyatakan usang tetapi akan tetap berada di API unuk setidaknya dua fitur terbitan. Peringatan akan ditampilkan ketika metode pengusangan dipanggil.
\nLihat Terbitan resmi untuk lebih rinci bagaimana skema penomoran versi Django bekerja, dan bagaimana fitur akan diusangkan.
\nWe'll only break backwards compatibility of these APIs without a deprecation\nprocess if a bug or security hole makes it completely unavoidable.
Pada umumnya, semaunya dicakupi di dokumentasi -- dengan pengecualian dari apapun di kawasan internal adalah dianggap stabil.
\nAda beberapa pengecualian pada kestabilan ini dan janji kecocokan-belakang.
\nJika kami menjadi waspada dari masalah keamanan -- semoga oleh seseorang mengikuti kebijakan pelaporan keamanan kami -- kami akan melakukan apapun yang dibutuhkan untuk memperbaikinya. Ini mungkin berarti merusak kecocokan sebelumnya; keamanan mengalahkan jaminan kecocokan.
\nBeberapa API secara eksplisit ditandai sebagai "internal" dalam sepsang jalan:
\nBeberapa dokumentasi mengacu ke internal dan menyebutkan mereka seperti itu. Jika dokumentasi mengatakan sesuatu adalah internal, kami berhak untuk mengubahnya.
Fungsi, metode, dan obyek lain diawali dengan dipimpin garis bawah (_). Ini adalah standar cara Phyton dari mengindikasikan bahwa sesuatu adalah private; jika cara apapun mulai dengan _ tunggal, itu adalah sebuah API internal.