Początki Debiana
Każdy pakiet w Debianie ma swojego opiekuna, który utrzymuje go w odpowiedniej wersji, a także dba o jego zgodność z polityką Debiana, utrzymuje zgodność z innymi pakietami i stara się, aby był on na odpowiednio wysokim poziomie. Użytkownicy zgłaszają błędy poprzez system zgłaszania błędów, a następnie opiekun stara się naprawić błędy w aplikacji. Zazwyczaj jeden opiekun zajmuje się jednym pakietem, jednak czasami niewielkie grupy deweloperów zajmują się jednym dużym pakietem lub grupą pakietów silnie ze sobą powiązanych.
Gdy opiekun chce wydać nową wersję pakietu najpierw wysyła go do katalogu „incoming” w archiwum pakietów Debiana. Serwer sprawdzi czy plik został poprawie wysłany i czy wszystkie wymagane pliki znajdują się w nim. Dla pewności sprawdza poprawność klucza OpenPGP opiekuna. Każdy z deweloperów Debiana posiada własny klucz publiczny. Pakiet podpisywany jest aby uniknąć wysłania go poprzez nieuprawnioną do tego osobę, która mogłaby wprowadzić modyfikację kodu mogącą wywołać obniżenie bezpieczeństwa systemu, bądź dodanie kodu łamiącego zasady Debiana lub licencji programu.
Jeżeli wysłany pakiet spełnił powyższe wymagania, zostaje przesunięty do obszaru nazwanego „pool”. Każdego dnia setki ze światowych mirrorów pobierają pakiety z tego katalogu. Wszystkie pobrane pakiety są dostępne tylko w niestabilnej gałęzi Debiana, która zawiera najnowsze wersje każdego pakietu.
Jednak nowy kod to także niesprawdzony kod, dlatego każdy pakiet z tej gałęzi jest udostępniany bez jakichkolwiek gwarancji bezpieczeństwa czy stabilności. Aby pakiet stał się kandydatem do następnego stabilnego wydania Debiana najpierw musi trafić do gałęzi testowej. Wymagania aby pakiet trafił do gałęzi testowej są następujące:
* musi być obecny przez pewną ilość dni w wydaniu niestabilnym;
* nie może mieć więcej błędów krytycznych wydania niż pakiet, który aktualnie znajduje się w testowej gałęzi. Błąd krytyczny wydania to taki błąd, który może negatywnie wpłynąć na bezpieczeństwo lub stabilność systemu i powinien być poprawiony przed następnym stabilnym wydaniem;
* musi być skompilowany we wszystkich oficjalnie wspieranych architekturach;
* nie może być zależny od pakietów które nie znajdują się w wydaniu testowym.
W ten sposób błąd krytyczny w jednym pakiecie od którego zależy wiele innych pakietów (np. biblioteka) może spowodować, że wiele pakietów nie trafi do testowej gałęzi.
Menadżer danego wydania stabilnego publikuje wytyczne dla deweloperów i decyduje o terminie wydania stabilnego. Jeżeli wszystkie ważne pakiety są we względnie nowych wersjach i są dostępne dla oficjalnie wspieranych architektur, a także wypełnione są założenia dla danego wydania następuje wydanie nowego wydania stabilnego. W jednym czasie wszystkie pakiety z gałęzi testowej stają się częścią wydania stabilnego. Operacja ta jest poprzedzona tzw. zamrożeniem gałęzi (ang. freeze), w tym najważniejszych podsystemów (jądro, biblioteki, kompilatory, interpretery języków skryptowych itp), w trakcie którego nie jest dozwolone umieszczanie nowych wersji pakietów w gałęzi testowej (poza aktualizacjami usuwającymi błędy ważne dla wydania czy wprowadzanie ważne poprawki bezpieczeństwa), ani dokonywanie zmian pociągających za sobą duże zmiany w archiwum (zmiana biblioteki mogłaby pociągnąć za sobą potrzebę przetestowania wszystkich zależnych od niej pakietów).
Jest możliwość, że stosunkowo stary pakiet, który jest rzadko uaktualniany będzie należał do więcej niż jednej gałęzi w tym samym czasie. Gałęzie są prostą metodą przechodzenia pakietu z katalogu „pool” do stabilnego wydania.