Sejak versi 1.0, penomoran terbitan Django bekerja seperti berikut:
\nVersi di nomori dalam bentuk A.B or A.B.C.
A.B adalah angka versi terbitan fitur. Setiap versi akan kebanyakan sesuai kebelakang dengan terbitan sebelumnya. Pengecualian ke aturan ini akan didaftarkan di catatan terbitan.
C adalah angka versi terbitan tanggalan, yang menaik untuk perbaikan kesalahan dan terbitan keamanan. Terbitan ini akan 100% sesuai kebelakang dengan terbitan tambalan sebelumnya. Hanya pengecualian ketika keamanan atau masalah kehilangan data tidak dapat diperbaiki tanpa merusak kesesuaian lebelakang. Jika ini terjadi, catatan terbitan akan menyediakan petunjuk peningkatan rincian.
Sebelum terbitan fitur baru, kami akan membuat terbitan alpha, beta, dan calon terbitan. Ini adalah bentuk A.B alpha/beta/rc N, yang berarti Nth alpha/beta/calon terbitan dari versi A.B.
Di git, setiap terbitan Django akan mempunyai etiket yang menunjukkan angka versi, ditandatangi dengan kunci terbitan Django. Selai itu, setiap rangkaian terbitan mempunai cabang tersendiri, dipanggil stable/A.B.x, terbitan perbaikan kesalahan/keamanan akan diterbitkan dari cabang-cabang tersebut.
For more information about how the Django project issues new releases for\nsecurity purposes, please see our security policies.
\nTerbitan fitur (A.B, A.B+1, dll.) akan terjadi kurang lebih setiap delapan bulan -- lihat release process untuk rincian. Terbitan ini akan mengandung fitur baru, perbaikan pada fitur yang ada, dan sebagainya.
\nTerbitan tambalan (A.B.C, A.B.C+1, etc.) akan diterbitkan ketika dibutuhkan, untuk memperbaiki kesalahan dan/atau masalah keamanan.
\nTerbitan ini akan 100% cocok dengan terbitan fitur yang terkait, meskipun ini sangat tidak mungkin untuk alasan keamanan atau untuk mencegah kehilangan data. Jadi jawaban pada "apakah Saya tingkatkan ke terbitan tambalan terakhir?" akan selalu "ya."
\nTerbitan fitur tertentu akan dirancang sebagai terbitan long-term support (LTS). Terbitan ini akan mendapatkan perbaikan keamanan dan kehilangan data diberlakukan untuk jaminan masa dari waktu, secara khusus tiga tahun.
\nLihat the download page untuk terbitan yang telah dirancang untuk dukungan jangka-panjang.
\nMulai dengan Django 2.0, angka versi akan menggunakan formulir longgar dari semantic versioning seperti bahwa setiap versi mengikuti LTS akan ditabrak ke versi "dot zero" selanjutnya. Sebagai contoh: 2.0, 2.1, 2.2 (LTS), 3.0, 3.1, 3.2 (LTS), etc.
\nSemVer membuatnya lebih mudah melihat sekilas bagaimana kesesuaian terbitan dengan satu sama lain. Itu juga membantu mengantisipasi kapan shim kesesuaian akan dipindahkan. Itu bukan murni formulir dari SemVer seeprti setiap terbitan fitur akan memiliki sedikit dokumentasi ketidaksesuaian kebelakang dimana jalur pengusangan tidak memungkinkan atau tidak berharga. Juga, pengusangan dimulai di terbitan LTS (X.2) akan dijatuhkan di terbitan bukan-titik-nol (Y.1) untuk mengakomodasi kebijakan kami dari menjaga pengusangan shim untuk setidaknya dua fitur terbitan. Baca bagian selanjutnya untuk sebuah contoh.
\nSebuah terbitan fitur mungkin mengusangkan fitur tertentu dari terbitan sebelumnya. Jika sebuah fitur diusangkan di terbitan fitur A.x, itu akan menlanjutkan bekerja di semua versi A.x (untuk semua versi dari x) tetapi menampilkan peringatan. Fitur diusangkan akan dipindahkan di terbitan B.0, atau B.1 untuk pengusangan fitur di terbitan fitur A.x terakhir untuk memastikan pengusangan selesai setidaknya 2 terbitan fitur.
\nJadi, sebagai contoh, jika kami memutuskan untuk mulai mengusangkan dari sebuah fungsi di Django 4.2:
\nDjango 4.2 akan mengandung tiruan kesesuaian-kebelakang dari fungsi yang akan memunculkan RemovedInDjango51Warning.
Django 5.0 (versi yang mengikuti 4.2) akan masih mengandung tiruan kesesuaian-kebelakang.
Django 5.1 akan memindahkan fitur sekaligus.
Peringatan diam secara awal. Anda dapat menyalakan tampilan dari peringatan ini dengan pilihan python -Wd.
Contoh umum lain:
\nX.0
X.1
X.2 LTS
Y.0: Menjatuhkan pengusangan shim ditambahkan di X.0 dan X.1.
Y.1: Menjatuhkan pengusangan shim ditambahkan di X.2.
Y.2 LTS: tidak ada pengusangan shim dijatuhkan (selagi Y.0 tidak lagi didukung, aplikasi pihak-ketiga butuh merawat kesesuaian kembali ke X.2 LTS untuk memudahkan LTS untuk peningkatan LTS).
Z.0: Menjatuhkan pengusangan shim ditambahkan di Y.0 dan Y.1.
Lihat juga panduan Mengusangkan fitur.
\nSetiap saat dalam waktu, tim pengembang Django akan mendukung kumpulan terbitan untuk beragam tingkatan. Lihat the supported versions section dari halaman unduhan untuk keadaan saat ini dari dukungan untuk setiap versi.
\nCabang pengembangan saat ini main akan mendapatkan fitur baru dan perbaikan kesalahan membutuhkan pemfaktoran ulang yang tidak sepele.
Patches applied to the main branch must also be applied to the last feature\nrelease branch, to be released in the next patch release of that feature\nseries, when they fix critical problems:
\nMasalah keamanan
Kesalahan kehilangan data.
Kesalahan tabrakan.
Kesalahan fungsionalitas utama dalam fitur baru dari terbitan stabil terakhir.
Pemulihan dari versi terlama Django diperkenalkan dalam deretan terbitan sekarang.
Aturan jempol adalah yaitu perbaikan akan di backport ke terbitan fitur terakhir untuk kesalahan yang akan mempunyai pencegahan terbitan di tempat pertama (pemblok terbitan).
\nPerbaikan keamanan dan kesalahan kehilangan data akan diberlakukan pada cabang utama saat ini, cabang terbitan fitur dua terakhir, dan cabang terbitan dukungan jangka-panjang didukung lainnya.
Perbaikan dokumentasi umumnya akan lebih bebas di backport ke cabang terbitan terakhir. Itu karena itu sangat menguntungkan memiliki dokumen untuk terbitan terakhir menjadi terbaru dan benar, dan resiko dari memperkenalkan pemulihan jauh dari perhatian.
Sebagai sebuah contoh nyata, pertimbangkan saat di waktu tengah jalan diantara terbitan dari Django 5.1 dan 5.2. Pada titik di waktu:
\nFitur akan ditambahkan pada induk pengembangan cabang utama, akan diterbitkan sebagai Django 5.2.
Perbaikan kesalahan genting akan diberlakukan pada cabang stable/5.1.x, dan terbitan seperti 5.1.1, 5.1.2, dll.
Security fixes and bug fixes for data loss issues will be applied to\nmain and to the stable/5.1.x, stable/5.0.x, and\nstable/4.2.x (LTS) branches. They will trigger the release of 5.1.1,\n5.0.5, 4.2.8, etc.
Documentation fixes will be applied to main, and, if easily backported, to\nthe latest stable branch, 5.1.x.
Django menggunakan jadwal terbitan berdasarkan-waktu, dengan fitur terbitan setiap delapan bulan atau lebih.
\nAfter each feature release, the release manager will publish a timeline for the\nnext feature release. The timeline for an upcoming feature release can be found\nin the corresponding wiki roadmap page, e.g.\nhttps://code.djangoproject.com/wiki/Version6.0Roadmap.
\nWork begins on the feature release A.B after the feature freeze of the\nprevious release, i.e. when the stable/A.B-1.x branch is forked.
You can find the current branch under active development in the\nDjango release process on Trac.
\nAll major and minor features, including deprecations and breaking changes, must\nbe merged by the feature freeze. Any features not done by this point will be\ndeferred to the next feature release.
\nAt this point, the stable/A.B.x branch will be forked from main.
After the alpha, all bug fixes merged in main are also backported to\nstable/A.B.x. Refactors are backported at the discretion of the merger.\nMergers will be more and more conservative with backports, to avoid introducing\nregressions.
In parallel to this phase, main can continue to receive new features, to be\nreleased in the A.B+1 cycle.
If there is still a consistent stream of release blockers coming in at the\nplanned release candidate date, a beta 2 will be released to encourage further\ntesting and the release candidate date will be pushed out ~1 month.
\nThe release candidate marks the string freeze, and it happens at least two\nweeks before the final release. Translators can then submit updated\ntranslations for inclusion in the final release. After this point, new\ntranslatable strings must not be added.
\nAfter the release candidate, only release blockers and documentation fixes are\nbackported.
\nIdeally, the final release will ship two weeks after the last release\ncandidate.
\nIf there are major bugs still being found 2 weeks after the release candidate,\nthere will be a decision on how to proceed (likely another release candidate\nwould be issued and the final release date will be pushed out).
\nSetelah terbitan fitur (sebagai contoh A.B), terbitan sebelumnya akan pergi kedalam suasana perbaikan kesalahan.
\nCabang untuk terbitan fitur sebelumnya (misalnya stable/A.B-1.x`) akan menyertakan perbaikan kesalahan. Perbaikan kesalahan genting pada utama harus juga diperbaiki pada cabang perbaikan kesalahan; ini berarti bahwa perbaikan butuh dengan rapi memisahkan perbaikan kesalahan dari tambahan fitur. Pengembang yang memperbaiki perbaikan pada master akan bertanggungjawab untuk juga memberlakukan perbaikan pada cabang perbaikan kesalahan sekarang.
\n