Product SiteDocumentation Site

1.6. Siklus hidup dari sebuah Rilis

Proyek secara simultan akan memiliki tiga sampai enam versi berbeda untuk setiap program, dinamakan Experimental, Unstable, Testing, Stable, Oldstable, dan bahkan Oldoldstable. Masing-masing mewakili fase yang berbeda dalam pengembangan. Untuk pemahaman yang baik, mari kita lihat perjalanan sebuah program, dari pemaketan awal hingga pemuatan dalam versi stabil Debian.

1.6.1. Status Experimental

Mari pertama-tama kita lihat kasus khusus dari distribusi Experimental: ini merupakan grup dari paket Debian yang berkaitan dengan perangkat lunak yang sedang dalam pengembangan, dan sesuai dengan namanya yang berarti belum tentu komplit. Tidak semuanya melalui langkah ini; beberapa pengembang menambah paket di sini untuk mendapatkan umpan balik dari pengguna yang lebih berpengalaman (atau lebih berani).
Selain itu, distribusi ini seringkali menampung modifikasi-modifikasi penting atas paket-paket dasar, yang integrasinya ke dalam Unstable dengan bug serius akan memiliki dampak kritikal. Inilah yang membuat distribusi ini benar-benar terisolasi, paketnya tidak pernah bermigrasi ke versi lain (kecuali dengan campur tangan langsung dari pengelola atau dari ftpmaster). Ini juga tidak mandiri: hanya suatu subset dari paket-paket yang ada yang hadir dalam Experimental, dan umumnya itu tidak termasuk sistem basis. Maka distribusi ini paling berguna dalam kombinasi dengan distribusi lain yang mandiri seperti Unstable.

1.6.2. Status Unstable

Mari kita kembali ke kasus paket pada umumnya. Pengelola membuat paket awal, yang mereka compile untuk versi Unstable dan menempatkannya pada server ftp-master.debian.org. Kejadian pertama melibatkan inspeksi dan validasi dari para ftpmaster. Perangkat lunak kemudian tersedia dalam distribusi Unstable, yang merupakan distribusi tedepan yang dipilih oleh para pengguna yang lebih peduli atas paket-paket mutakhir daripada khawatir atas bug-bug serius. Mereka menemukan program tersebut dan mencobanya.
Jika mereka menemukan bug, mereka melapor pada pengelola paket. Pengelola paket selanjutnya secara berkala menyiapkan versi yang telah diperbaiki, untuk diunggah ke server.
Setiap paket yang baru dimutakhirkan, diperbaharui pada semua cermin Debian di dunia dalam kurang dari enam jam. Para pengguna selanjutnya menguji perbaikan dan mencari masalah lain akibat modifikasi. Beberapa pemutakhiran mungkin terjadi secara cepat. Pada waktu-waktu ini, saatnya robot autobuilder beraksi. Paling sering, pengelola hanya memiliki satu PC tradisional dan telah mengcompile paketnya pada arsitektur amd64 (atau i386); autobuilder mengambil alih dan secara otomatis mengcompile versi-versi untuk semua arsitektur lain. Beberapa kompilasi bisa jadi gagal; pengelola selanjutnya akan menerima laporan bug yang menandakan masalah, yang kemudian akan diperbaiki pada versi selanjutnya. Saat suatu bug ditemukan oleh spesialis pada arsitektur tertentu, laporan bug mungkin sudah dilengkapi dengan patch yang siap pakai.
Kompilasi sebuat paket oleh autobuilders

Gambar 1.2. Kompilasi sebuat paket oleh autobuilders

1.6.3. Migrasi ke Testing

Tak lama setelah ini, paket akan matang; ter-compile pada semua arsitektur, tidak akan mengalami modifikasi belakangan. Hal ini menjadi kandidat untuk dimuat dalam distribusi Testing — sebuah grup paket Unstable dipilih berdasarkan kriteria terukur. Setiap hari sebuah program secara otomatis memilih paket untuk dimasukkan dalam Testing, berdasarkan elemen menjamin suatu tingkat tertentu kualitas:
  1. kurang bug kritis, atau paling tidak lebih sedikit dari versi yang dimasukkan dalam Testing;
  2. paling tidak 10 hari dihabiskan dalam Unstable, waktu yang cukup untuk menemukan dan melaporkan masalah serius;
  3. sukses compile pada semua arsitektur yang resmi didukung;
  4. dependensi dapat dipenuhi dalam Testing, atau paling tidak dapat dipindahkan bersama dengan paket dalam pertanyaan.
Sistem ini jelas tidak sempurna; bug kritis ditemukan berkala dalam paket yang dimuat dalam Testing. Secara umum masih efeketif, dan Testing mengalami masalah yang lebih sedikit dari Unstable, yang bagi kebanyakan, menjadi kompromi yang baik antara kestabilan dan kebaruan.

1.6.4. Promosi dari Testing ke Stable

Sekarang mari kita beranggapan bahwa paket kita telah dimasukkan dalam Testing. Selama itu masih memiliki ruang untuk perbaikan, pengelolanya harus melanjutkan untuk meningkatkan dan memulai ulang proses dari Unstable (namun dengan inklusi berikutnya dalam Testing umumnya lebih cepat: Jika tidak berubah secara signifikan, semua dependensi sudah tersedia). Saat mencapai keadaan sempurna, pengelola telah menyelesaikan pekerjaannya. Langkah selanjutnya adalah pemuatan dalam distribusi Stable, yang pada kenyataannya merupakan penyalinan dari Testing pada momen yang dipilih oleh Manajer Rilis. Idealnya keputusan ini dibuat saat installer siap dan saat tidak ada program dalam Testing yang memiliki bug kritis.
Karena momen ini sesungguhnya tidak pernah terjadi, pada praktiknya, Debian harus berkompromi: menghapus paket yang pengelolanya telah gagal mengoreksi bug tepat waktu atau setuju merilis distribusi dengan beberapa bug dalam ribuan program. Manajer Rilis sebelumnya akan mengumumkan masa freeze, saat setiap update ke Testing harus disetujui. Tujuan di sini adalah untuk mencegah setiap versi baru (dan bug baru), dan hanya menyetujui bug kritis.
Perjalan Sebuah Paket melalui beragam versi Debian

Gambar 1.3. Perjalan Sebuah Paket melalui beragam versi Debian

Setelah rilis versi stabil baru, Stable Release Managers mengelola pengembangan selanjutnya (disebut “revisi”, contoh: 7.1, 7.2, 7.3 untuk versi 7). Pemutakhiran ini secara sistematis memuat semua security patches. Mereka juga akan memasukkan koreksi paling penting (pengelola paket harus membuktikan kegawatan dari masalah yang ingin mereka perbaiki agar update mereka dimasukkan).
Pada akhir perjalanan, paket hipotetis kita sekarang disertakan dalam distribusi stabil. Perjalanan ini, bukan tanpa kesulitan, menjelaskan penundaan signifikan yang memisahkan rilis-rilis Debian Stable. Ini memberikan kontribusi, secara keseluruhan, ke reputasinya untuk kualitas. Selain itu, sebagian besar pengguna puas menggunakan salah satu dari tiga distribusi yang serentak tersedia. Administrator sistem, yang lebih mengutamakan stabilitas server mereka, tidak perlu versi terbaru dan terbesar dari GNOME; mereka dapat memilih Debian Stable, dan mereka akan puas. Pengguna akhir, lebih tertarik pada versi terbaru dari GNOME atau KDE daripada stabilitas yang kokoh, akan menemukan Debian Testing sebagai kompromi yang baik antara kurangnya masalah serius dan perangkat lunak yang relatif mutakhir. Akhirnya, pengembang dan pengguna yang lebih berpengalaman mungkin menjadi pionir, menguji semua perkembangan terbaru di Debian Unstable tepat di luar pintu gerbang, dengan risiko menderita sakit kepala dan bug yang melekat dalam setiap versi baru program. Untuk masing-masing Debian mereka sendiri!
Path kronologis dari program yang dipaketkan oleh Debian

Gambar 1.4. Path kronologis dari program yang dipaketkan oleh Debian

1.6.5. Status Oldstable dan Oldoldstable

Setiap rilis Stable memiliki harapan umur hidup sekitar 5 tahun dan mengingat bahwa rilis cenderung terjadi setiap 2 tahun, ada sampai dengan 3 rilis yang didukung pada setiap saat. Ketika rilis stabil versi terbaru dilaksanakan, rilis sebelumnya menjadi Oldstable dan yang sebelumnya menjadi Oldoldstable.
Long Term Support (LTS, Dukungan Jangka Panjang) dari rilis Debian ini adalah inisiatif baru: para kontributor individual dan perusahaan bergabung untuk membuat tim Debian LTS. Rilis yang lebih tua yang tidak lagi didukung oleh tim keamanan Debian jatuh di bawah tanggung jawab ini tim baru.
Tim keamanan Debian menangani dukungan keamanan pada rilis Stable saat ini dan juga di rilis Oldstable (tapi hanya selama diperlukan untuk memastikan satu tahun tumpang tindih dengan rilis stabil saat ini). Ini berarti dukungan sekitar tiga tahun untuk setiap rilis. Tim Debian LTS menangani dukungan keamanan (dua) tahun terakhir sehingga setiap rilis mendapat keuntungan berupa minimal 5 tahun dukungan sehingga pengguna dapat meningkatkan dari versi N ke N+2.