1.6. Levenscyclus van een Vrijgave
Het project zal simultaan drie tot zes verschillende versies van ieder programma hebben, genoemd Experimenteel, Onstabiel, Testen, Stabiel, Oudstabiel, en zelfs Oudoudstabiel. Iedere correspondeert met een andere fase in de ontwikkeling. Voor een goed begrip, laat ons eens kijken naar de reis van een programma, van het initieel inpakken tot de toevoeging aan een stabiele versie van Debian.
1.6.1. De Experimentele Status
Laten we eerst in het bijzonder kijken naar de Experimentele distributie: dit is een groep van Debian pakketten die overeenkomen met de software die momenteel in ontwikkeling is, en niet noodzakelijk compleet, wat zijn naam verklaart. Niet alles gaat voorbij dit punt; sommige ontwikkelaars voegen hier pakketten toe on feedback te krijgen van meer ervaren (of dapperder) gebruikers.
Anderzijds herbergt deze distributie regelmatig belangrijke aanpassingen aan basis pakketten, wiens toevoeging aan Onstabiel met grote fouten kritieke gevolgen zou hebben. Het is dus een compleet geïsoleerde distributie, zijn pakketten migreren nooit naar een andere versie (behalve door directie uitdrukkelijke interventie van de beheerders of de ftpmasters). Het is ook geen op zichzelf staand systeem: enkel een kleine subset van de bestaande pakketten is beschikbaar in Experimental en het bevat in het algemeen geen basis systeem. Deze distributie is daarom het meest bruikbaar in combinatie met een andere, op zichzelf staande, distributie zoals Onstabiel.
1.6.2. De Onstabiele Status
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.
Indien ze een fout opmerken, rapporteren ze deze aan de pakket onderhouder. De onderhouder maakt dan regelmatig gecorrigeerde versies welk ze dan uploaden naar de 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 (or they opted for a source-only upload, thus without any precompiled package); 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.
1.6.3. Migratie naar Testen
Iets later, als het pakket rijp is; ge-compileert op alle architecturen, als het geen recente aanpassigen heeft gehad. Is het dan een kandidaat voor toevoeging aan de Testen distributie - een groep van Onstabiele pakketten gekozen aan de hand van enkele kwantificeerbare criteria. Iedere dag worden programma's automatisch geselecteerd om toegevoegd te worden aan Testen volgens elementen die een bepaald niveau van kwaliteit garanderen:
gebrek aan kritieke fouten of tenminste minder dan in de huidige versie beschikbaar in Testen
at least 5 days spent in Unstable, which is usually sufficient time to find and report any serious problems (successfully passing the package's own test suite, if it has one, reduces that time);
Succesvolle compilatie op alle officieel ondersteunde architecturen;
dependencies that can be satisfied in Testing, or that can at least be moved there together with the package in question;
automatic quality tests of the package (autopkgtest) — if defined — don't show any regression.
Dit systeem is zeker niet onfeilbaar; kritieke fouten worden regelmatig gevonden in Testen maar, het is in het algemeen bruikbaar, en Testen bevat veel minder problemen dan Onstabiel, wat voor velen een goed compromis is tussen stabiliteit en nieuwigheid.
1.6.4. De promotie vanTesten naar Stabiel
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.
Omdat dit moment in de praktijk nooit bereikt wordt moet Debian compromissen sluiten: pakketten waarvan de onderhouder niet tijdig het probleem heeft opgelost verwijderen of akkoord gaan om een distributie met enkele fouten, in de duizende programma's, vrij te geven. De Vrijgave Manager zal eerder een bevries periode aangekondigd hebben, gedurende welke iedere update aan Testen goedgekeurd moeten worden. Het doel hiervan is om te voorkomen dat enige nieuwe versie (en zijn nieuwe fouten) geïntroduceerd worden en om enkel updates die fouten oplossen goed te keuren.
After the release of a new stable version, the Stable Release Managers manage all further development (called “revisions”, ex: 7.1, 7.2, 7.3 for version 7). These updates systematically include all security patches. They will also include the most important corrections (the maintainer of a package must prove the gravity of the problem that they wish to correct in order to have their updates included).
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 Plasma 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!
1.6.5. De Oudstabiele en Oudoudstabiele Status
Iedere Stabiele vrijgave heeft een verwachte leeftijd van ongeveer 5 jaar en aangezien dat vrijgaven de neiging hebben om iedere 2 jaar plaats te vinden kunnen er op een gegeven tijdstip tot 3 ondersteunde vrijgaven zijn. Wanneer een nieuwe stabiele vrijgave gebeurd zal de vorige vrijgave Oudstabiel worden en diegene daarvoor zelfs zal Oudoudstabiel worden.
Deze Lange Termijn Ondersteuning (LTS) van Debian vrijgaven is een recent initiatief: individuele bijdragers en bedrijven bundelden hun krachten om het Debian LTS team te creëren. Oudere vrijgaven die niet langer ondersteund worden door het Debian Beveiligings-Team vallen onder de verantwoordelijkheid van dit nieuwe 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, for example from Debian 8 "Jessie" to Debian 10 "Buster".