# Dokumentasi Django 4.2.9.dev20231204082947

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

See also the Mengusangkan fitur guide.

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

- The current development branch `main` will get new features and bug fixes requiring non-trivial refactoring.

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

- Security fixes and data loss bugs will be applied to the current main branch, the last two feature release branches, and any other supported long-term support release branches.

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

- Features will be added to the development main branch, to be released as 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.

Setelah setiap terbitan fitur, pengelola terbitan akan mengumumkan linimasa untuk terbitan masa depan selanjutnya.

### Daur terbitan

Setiap daur terbitan terdiri dari tiga bagian:

#### Tahap satu: usulan fitur

Fase pertama dari pengolahan terbitan akan menyertakan menetapkan apa fitur utama untuk disertakan di versi selanjutnya. Ini harus urusan bagus dari pekerjaan pendahuluan pada fitur-fitur itu -- bekerja kode truf rancangan lengkap.

Fitur utama untuk terbitan akan datang akan ditambahkan pada halaman peta jalan wiki, sebagai contoh https://code.djangoproject.com/wiki/Version1.11Roadmap.

#### Tahap dua: pengembangan

Bagian kedua dari jadwal terbitan adalah periode bekerja "heads-down". menggunakan peta jalan dihasilkan pada akhir fase satu, kami akan semua bekerja sangat keras untuk mendapatkan semuanya selesai.

Pada akhir tahap kedua, fitur yang belum selesai akan ditunda sampai terbitan selanjutnya.

Phase two will culminate with an alpha release. At this point, the `stable/A.B.x` branch will be forked from `main`.

#### Tahap tiga: memperbaiki kesalahan

Bagian terakhir dari siklus terbitan sihabiskan memperbaiki kesalahan -- tidak ada fitur baru akan diterima selama waktu ini. Kami akan mencoba meerbitkan terbitan beta satu bulan setelah alpha dan calon terbitan satu bulan setelah beta.

Calon terbitan menandai string freeze, dan itu terjadi setidaknya dua minggu sebelum terbitan akhir. Setelah titik ini, deretan karakter baru yang dapat diartikan harus tidak ditambahkan.

During this phase, mergers will be more and more conservative with backports, to avoid introducing regressions. After the release candidate, only release blockers and documentation fixes should be backported.

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

### Terbitak perbaikan-kesalahan

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

The branch for the previous feature release (e.g. `stable/A.B-1.x`) will include bugfixes. Critical bugs fixed on main must also be fixed on the bugfix branch; this means that commits need to cleanly separate bug fixes from feature additions. The developer who commits a fix to main will be responsible for also applying the fix to the current bugfix branch.