Pengolahan terbitan Django¶

Terbitan resmi¶

Sejak versi 1.0, penomoran terbitan Django bekerja seperti berikut:

Versi 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.

Untuk informasi lebih tentang bagaimana proyek Django mengeluarkan terbitan baru untuk tujuan keamanan, silahkan lihat our security policies.

Terbitan akan datang¶

Terbitan 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.

Terbitan tambalan¶

Terbitan tambalan (A.B.C, A.B.C+1, etc.) akan diterbitkan ketika dibutuhkan, untuk memperbaiki kesalahan dan/atau masalah keamanan.

Terbitan 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."

Terbitan dukungan jangka-panjang¶

Terbitan 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.

Lihat the download page untuk terbitan yang telah dirancang untuk dukungan jangka-panjang.

Irama terbitan¶

Mulai 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.

SemVer 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.

Kebijakan bantahan¶

Sebuah 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.

Jadi, sebagai contoh, jika kami memutuskan untuk mulai mengusangkan dari sebuah fungsi di Django 4.2:

Django 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:

X.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.

Versi didukung¶

Setiap 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.

Cabang 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 release branch, to be released in the next patch release of that feature series, when they fix critical problems:
- Masalah 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).
Perbaikan 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:

Fitur 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 main and to the stable/5.1.x, stable/5.0.x, and stable/4.2.x (LTS) branches. They will trigger the release of 5.1.1, 5.0.5, 4.2.8, etc.
Documentation fixes will be applied to main, and, if easily backported, to the latest stable branch, 5.1.x.

Mengolah terbitan¶

Django menggunakan jadwal terbitan berdasarkan-waktu, dengan fitur terbitan setiap delapan bulan atau lebih.

After each feature release, the release manager will publish a timeline for the next feature release. The timeline for an upcoming feature release can be found in the corresponding wiki roadmap page, e.g. https://code.djangoproject.com/wiki/Version6.0Roadmap.

Feature release schedule and stages¶

Active development / Pre-feature freeze¶

Work begins on the feature release A.B after the feature freeze of the previous release, i.e. when the stable/A.B-1.x branch is forked.

You can find the current branch under active development in the Django release process on Trac.

Feature freeze / Alpha release¶

All major and minor features, including deprecations and breaking changes, must be merged by the feature freeze. Any features not done by this point will be deferred to the next feature release.

At this point, the stable/A.B.x branch will be forked from main.

Non-release blocking bug fix freeze / Beta release¶

After the alpha, all bug fixes merged in main are also backported to stable/A.B.x. Refactors are backported at the discretion of the merger. Mergers will be more and more conservative with backports, to avoid introducing regressions.

In parallel to this phase, main can continue to receive new features, to be released in the A.B+1 cycle.

Translation string freeze / Release candidate release¶

If there is still a consistent stream of release blockers coming in at the planned release candidate date, a beta 2 will be released to encourage further testing and the release candidate date will be pushed out ~1 month.

The release candidate marks the string freeze, and it happens at least two weeks before the final release. Translators can then submit updated translations for inclusion in the final release. After this point, new translatable strings must not be added.

After the release candidate, only release blockers and documentation fixes are backported.

Final release¶

Ideally, the final release will ship two weeks after the last release candidate.

If there are major bugs still being found 2 weeks after the release candidate, there will be a decision on how to proceed (likely another release candidate would be issued and the final release date will be pushed out).

Terbitak perbaikan-kesalahan¶

Setelah terbitan fitur (sebagai contoh A.B), terbitan sebelumnya akan pergi kedalam suasana perbaikan kesalahan.

Cabang 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.