Product SiteDocumentation Site

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 noodzakelijkerwijs voltooid, wat daarmee de naam verklaart. Niet alles gaat voorbij dit punt; sommige ontwikkelaars voegen hier pakketten toe om 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

Laten we terug gaan naar het geval van een typisch pakket. De beheerder maakt een initieel pakket, welke ze compileren voor de Unstable versie en plaatsen het op de ftp-master.debian.org server. Dit eerste voorval omvat inspectie en validatie van de ftpmasters. De software is dan beschikbaar in de Unstable distributie, welke de “cutting edge” distributie naar keuze is van gebruikers die bezorgder zijn over het hebben van de nieuwste pakketten dan over serieuze fouten. Ze ontdekken het programma en testen het dan.
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. The maintainer uploads the package sources (without any precompiled package). The autobuilders take over and automatically compile versions for all supported 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.
Compileren van een pakket door de autobuilders

Afbeelding 1.2. Compileren van een pakket door de autobuilders

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:
  1. Succesvolle compilatie op alle officieel ondersteunde architecturen;
  2. gebrek aan kritieke fouten of tenminste minder dan in de huidige versie beschikbaar in Testen
  3. Er wordt op zijn minst 5 dagen verbleven in Onstable, wat meestal voldoende tijd is om serieuze problemen te vinden en te rapporteren (het succesvol doorlopen van het pakket eigen testsysteem, als het dat heeft, vermindert die tijd);
  4. afhankelijkheden die voldaan kunnen worden in Testen of die er tenminste samen met het pakket in kwestie naar toe verhuisd kunnen worden;
  5. Automatische kwaliteitstests van het pakket(autopkgtest— mits gedefinieerd — tonen geen regressie.
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

Laten we er nu van uit gaan dat ons pakket in toegevoegd aan Testen. Zolang als er plaats is voor verbetering moeten de onderhouders verder gaan met het te verbeteren en het proces opnieuw starten vanuit Onstabiel (maar zijn latere toevoeging aan Testen zal in het algemeen sneller gaan, behalve als er significante aanpassingen zijn, want alle afhankelijkheden zijn reeds beschikbaar). Wanneer het de perfectie bereikt is de ontwikkelaar klaar met zijn werk. De volgende stap is het toevoegen aan de Stabiele distributie, welke in werkelijkheid een kopie is van Testen op een gegeven moment bepaalt door de Vrijgave Manager. idealiter wordt deze beslissing genomen wanneer het installatie programma klaar is en wanneer geen programma in Testen bekende kritieke fouten heeft.
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.
De weg van een pakket doorheen de verschillende Debian versies

Afbeelding 1.3. De weg van een pakket doorheen de verschillende Debian versies

After the release of a new stable version, the Stable Release Managers manage all further development (called “revisions”, ex: 10.1, 10.2, 10.3 for version 10). 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!
Chronologisch pad van een programma ingepakt door Debian

Afbeelding 1.4. Chronologisch pad van een programma ingepakt door 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 release benefits from at least 5 years of support and so that users can upgrade from version N to N+2, for example, from Debian 9 Stretch to Debian 11 Bullseye.