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.

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.

  • Master pengembangan saat ini akan mendapatkan fitur baru dan perbaikan kesalahan membutuhkan refaktor bukan sepele.

  • Tambalan-tambalan diberlakukan ke cabang master harus juga diberlakukan ke cabang terbitan fitur terakhir. untuk diterbitkan di tambalan terbitan selanjutnya dari rangkaian fitur, ketika mereka memperbaiki masalah-masalah kritis:

    • Masalah keamanan
    • Kesalahan kehilangan data.
    • Kesalahan tabrakan.
    • Kesalahan fungsionalitas utama dalam fitur baru dari terbitan stabil terakhir.
    • Pemulihan dari versi terlama dari Django.

    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 master 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, 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.
  • Perbaikan keamanan dan perbaikan kesalahan untuk masalah kehilangan data akan diberlakukan pada (LTS) cabang master dan pada stable/5.1.x, stable/5.0.x, dan stable/4.2.x. Mereka akan memicu terbitan dari 5.1.1, 5.0.5, 4.2.8, dll.
  • Perbaikan dokumentasi akan diberlakukan pada master, dan jika dengan mudah dihubungkan, ke cabang stabil terakhir, 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.

Tahap kedua akan berujung dengan terbitan alpha. Pada titik ini, cabang stable/A.B.x akan di cabangkan dari master.

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.

Selama tahap ini, pembuat perbaikan akan lebih dan lebih kolot dengan backport, untuk menghindari memperkenalkan pemulihan. Setelah kandidat terbitan, hanya pemblok terbitan dan dokumentasi tetap harus di backport.

Secara sejajar pada tahap ini, master dapat menerima fitur baru, untuk diterbitkan dalam siklus A.B+1.

Terbitak perbaikan-kesalahan

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

Cabang untuk terbitan fitur sebelumnya (sebagai contoh stable/A.B-1.x) akan menyertakan perbaikan kesalahan. Perbaikan kesalahan genting pada master 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.

Back to Top