Product SiteDocumentation Site

1.6. Siklus hidup dari sebuah Rilis

The project will simultaneously have three to six different versions of each program, named Experimental, Unstable, Testing, Stable, Oldstable, and even Oldoldstable. Each one corresponds to a different phase in development. For a good understanding, let us take a look at a program's journey, from its initial packaging to inclusion in a stable version of 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).
Otherwise, this distribution frequently houses important modifications to base packages, whose integration into Unstable with serious bugs would have critical repercussions. It is, thus, a completely isolated distribution, its packages never migrate to another version (except by direct, express intervention of the maintainer or the ftpmasters). It is also not self-contained: only a subset of the existing packages are present in Experimental, and it generally does not include the base system. This distribution is therefore mostly useful in combination with another, self-contained, distribution such as Unstable.

1.6.2. Status Unstable

Let us turn back to the case of a typical package. The maintainer creates an initial package, which they compile for the Unstable version and place on the ftp-master.debian.org server. This first event involves inspection and validation from the ftpmasters. The software is then available in the Unstable distribution, which is the “cutting edge” distribution chosen by users who are more concerned with having up to date packages than worried about serious bugs. They discover the program and then test it.
Jika mereka menemukan bug, mereka melapor pada pengelola paket. Pengelola paket selanjutnya secara berkala menyiapkan versi yang telah diperbaiki, untuk diunggah ke server.
Every newly updated package is updated on all Debian mirrors around the world within six hours. The users then test the corrections and search for other problems resulting from the modifications. Several updates may then occur rapidly. During these times, autobuilder robots come into action. Most frequently, the maintainer has only one traditional PC and has compiled their package on the amd64 (or i386) architecture; the autobuilders take over and automatically compile versions for all the other architectures. Some compilations may fail; the maintainer will then receive a bug report indicating the problem, which is then to be corrected in the next versions. When the bug is discovered by a specialist for the architecture in question, the bug report may come with a patch ready to use.
Kompilasi sebuat paket oleh autobuilders

Gambar 1.2. Kompilasi sebuat paket oleh autobuilders

1.6.3. Migration 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

Let us suppose that our package is now included in Testing. As long as it has room for improvement, its maintainer must continue to improve it and restart the process from Unstable (but its later inclusion in Testing is generally faster: unless it changed significantly, all of its dependencies are already available). When it reaches perfection, the maintainer has completed their work. The next step is the inclusion in the Stable distribution, which is, in reality, a simple copy of Testing at a moment chosen by the Release Manager. Ideally this decision is made when the installer is ready, and when no program in Testing has any known critical bugs.
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).
At the end of the journey, our hypothetical package is now included in the stable distribution. This journey, not without its difficulties, explains the significant delays separating the Debian Stable releases. This contributes, over all, to its reputation for quality. Furthermore, the majority of users are satisfied using one of the three distributions simultaneously available. The system administrators, concerned above all about the stability of their servers, don't need the latest and greatest version of GNOME; they can choose Debian Stable, and they will be satisfied. End users, more interested in the latest versions of GNOME or KDE than in rock-solid stability, will find Debian Testing to be a good compromise between a lack of serious problems and relatively up to date software. Finally, developers and more experienced users may blaze the trail, testing all the latest developments in Debian Unstable right out of the gate, at the risk of suffering the headaches and bugs inherent in any new version of a program. To each their own Debian!
Path kronologis dari program yang dipaketkan oleh Debian

Gambar 1.4. Path kronologis dari program yang dipaketkan oleh Debian

1.6.5. The Oldstable and Oldoldstable Status

Each Stable release has an expected lifetime of about 5 years and given that releases tend to happen every 2 years, there can be up to 3 supported releases at a given point of time. When a new stable release happens, the former release becomes Oldstable and the one even before becomes Oldoldstable.
This Long Term Support (LTS) of Debian releases is a recent initiative: individual contributors and companies joined forces to create the Debian LTS team. Older releases which are no longer supported by the Debian security team fall under the responsibility of this new team.
The Debian security team handles security support in the current Stable release and also in the Oldstable release (but only for as long as is needed to ensure one year of overlap with the current stable release). This amounts roughly to three years of support for each release. The Debian LTS team handles the last (two) years of security support so that each releases benefits from at least 5 years of support and so that users can upgrade from version N to N+2.