Product SiteDocumentation Site

1.6. Livsløpet til en versjon

Prosjektet vil samtidig ha tre til seks ulike versjoner av hvert program med navn Experimental, Unstable, Testing, Stable, Oldstable, til og med Oldoldstable. Hver av dem svarer til en forskjellig fase i utviklingen. For god forståelse, la oss se på programmets reise fra sin opprinnelige pakke til å komme med i en stabil versjon av Debian.

1.6.1. The Experimental Status (Den eksperimentelle status)

Først la oss se på det spesielle tilfellet med Experimental distribusjonen: Dette er en gruppe Debian-pakker der navnet forklarer at denne programvaren er i utvikling, og ikke nødvendigvis ferdig. Ikke alt passerer gjennom dette trinnet. Noen utviklere legger til pakker her for å få tilbakemeldinger fra mer erfarne (eller modigere) brukere.
Ellers huser denne distribusjonen ofte viktige endringer i grunnpakkene, som, hvis de blir lagt inn i Unstable med alvorlige feil, ville fått kritiske konsekvenser. Den er dermed en helt isolert distribusjon, der pakkene aldri migrerer til en annen versjon (unntatt ved direkte, rask intervensjon fra vedlikeholderen eller ftp-lederne). Den er heller ikke selvstendig: Bare en undergruppe av de eksisterende pakkene er med i Experimental, og den inneholder vanligvis ikke basissystemet. Denne distribusjonen er derfor nyttigst i kombinasjon med en annen, selvstendig, distribusjon som f.eks. Unstable.

1.6.2. Den Unstable Status

La oss gå tilbake til tilfellet med en typisk pakke. Utvikleren skaper en innledende pakke, som de bygger for Unstable-versjonen, og plasserer på ftp-master.debian.org-tjeneren. Dette første tiltaket involverer inspeksjon og godkjenning fra ftp-lederne. Programvaren er deretter tilgjengelig i Unstable-distribusjonen, som er «cutting edge»-distribusjon, valgt av brukere som er mer opptatt av å ha oppdaterte pakker, enn av bekymring for alvorlige feil. De vil finne ut mer om programmet, og deretter teste det.
Hvis de treffer på bugs, rapporterer de dem til pakkevedlikeholderen. Vedlikeholderen forbereder regelmessig korrigerte versjoner, som lastes opp til serveren.
Hver nylig oppdaterte pakke blir oppdatert i løpet av 6 timer på alle Debian-speil rundt om i verden. Brukerne tester deretter korrigeringer, og søker etter andre problemer som følger av disse endringene. Flere oppdateringer kan da skje raskt. I dag er også roboter for autobygging tatt i bruk. Oftest har vedlikeholderen bare en tradisjonell PC, og har utarbeidet sin pakke på AMD64(eller i386)-arkitektur. Autobyggere tar over og bygger automatisk versjoner for alle de andre arkitekturene. Noen kompileringer kan mislykkes. Vedlikeholderen vil da motta en feilrapport som viser problemet, som så blir rettet opp i de følgende versjonene. Når feilen er oppdaget av en spesialist for arkitekturen det gjelder, kan en feilrapport komme med en patch klar til bruk.
Autobyggernes pakkebygging

Figur 1.2. Autobyggernes pakkebygging

1.6.3. Migrasjon til Testing

Litt senere vil pakken ha modnet. Utarbeidet på alle arkitekturer, vil den ikke ha gjennomgått modifikasjoner nylig. Da er den en kandidat for å bli tatt inn i Testing distribution — en gruppe av Unstable-pakker valgt i henhold til noen målbare kriterier. Hver dag velger et program automatisk pakker som skal med i Testing, etter komponenter som sikrer et visst kvalitetsnivå:
  1. mangel av kritiske bugs, eller, i det minste færre i den versjon som for tiden er inkludert i Testing;
  2. minst ti dagers opphold i Unstable, som er tilstrekkelig tid til å finne og rapportere om eventuelle alvorlige problemer;
  3. vellykket samling av alle offisielt støttede arkitekturer;
  4. avhengigheter som kan imøtekommes i Testing, eller som i det minste kan flyttes dit sammen med den pakken det gjelder.
Dette systemet er helt klart ikke ufeilbarlig. Kritiske feil finnes ofte i pakker som inngår i Testing. Likevel, det er i alminnelighet effektivt, og Testing gir langt færre problemer enn Unstable, og blir for mange et godt kompromiss mellom stabilitet og nytt.

1.6.4. Opprykk fra Testing til Stable

La oss gå ut fra at vår pakke nå er kommet med i Testing. Så lenge det er rom for forbedring, må den vedlikeholdsansvarlige fortsette å forbedre den, og starte prosessen fra Ustabil (men senere inlegging i Testing er generelt raskere: Med mindre den har endret seg betydelig, foreligger alle avhengigheter allerede). Når den er blitt perfekt, har den ansvarlige avsluttet sitt arbeid. Det neste trinnet er å legge den inn i Stable-distribusjonen, som i realiteten er en enkel kopi av Testing på et tidspunkt valgt av den utgiveransvarlige. Ideelt sett blir beslutningen tatt når installasjonsprogrammet er ferdig, og når ingen programmer i Testing har noen kjente kritiske bugs.
Siden dette øyeblikket aldri i praksis er kommet, må Debian kompromisse: Ta ut pakker der utgiveransvarlig har unnlatt å rette feil i tide, eller godta i å utgi en distribusjon med noen bugs i tusenvis av programmer. Utgiveransvarlig har tidligere annonsert en frys-periode, der hver oppdatering avTesting må godkjennes. Målet her er å forhindre nye versjoner (og dets nye feil), og kun godkjenne oppdateringer som fikser feil.
En pakkes vei gjennom de ulike Debian-versjonene

Figur 1.3. En pakkes vei gjennom de ulike Debian-versjonene

Etter utgivelsen av en ny stabil versjon, styrer Stable Release Manager all videre utvikling (kalt «revisjoner», f. eks. 7.1, 7.2, 7.3 for versjon 7). Disse oppdateringene inkluderer automatisk alle sikkerhetsoppdateringer. De vil også inkludere de viktigste korreksjonene (vedlikeholderen av en pakke må bevise alvoret i problemet som de ønsker å korrigere, for å få sine oppdateringer inkludert).
På slutten av turen er vår hypotetiske pakke nå inkludert i den stabile distribusjonen. Denne reisen, ikke uten sine problemer, forklarer de betydelige forsinkelsene som adskiller Debian Stable utgivelser. Dette bidrar, mer enn noe, til deres rykte for kvalitet. Videre er de fleste av brukerne fornøyd med en av tre distribusjoner som er tilgjengelig samtidig. Systemadministratorene som fremfor alt er berørt av stabiliteten hos serverne sine, trenger ikke den nyeste og beste versjonen av GNOME. De kan velge Debian Stable, og de vil være fornøyd. Sluttbrukere som er mer interessert i de nyeste versjonene av GNOME eller KDE enn i bunnsolid stabilitet, vil finne at Debian Testing er et godt kompromiss mellom mangel på seriøse problemer og relativt oppdatert programvare. Og utviklere og erfarne brukere kan leve på knivseggen, og teste de siste nyvinningene i Debian Unstable rett ut av boksen, med fare for å oppleve hodepine og bugs i en ny versjon av et program. Til alle sin egen Debian!
Kronologisk bane for et program pakket av Debian

Figur 1.4. Kronologisk bane for et program pakket av Debian

1.6.5. Den gamle Oldstable og Oldoldstable Status

HverStable-utgave har en forventet levetid på ca 5 år, og gitt at utgivelser pleier å komme hvert 2. år, kan det være opp til tre utgivelser som støttes på et gitt tidspunkt. Når en ny stabil utgivelse skjer, blir den tidligere utgivelsenOldstable, og den ene tidligere Oldoldstable .
Denne Debian-utgaven med langvarig støtte (LTS) er av ny dato. Individuelle bidragsytere og bedrifter har gått sammen om å opprette Debian LTS-gruppen. Eldre utgivelser som ikke lenger støttes av Debians sikkerhetsgruppe kommer inn under ansvarsområdet til denne nye gruppen.
Debian sikkerhetsteam håndterer sikkerhetsstøtte i den til enhver tid aktuelle Stable-utgaven, og også i Oldstable-utgaven, (men bare så lenge det er nødvendig for å sikre ett års overlapping med den nåværende stabile utgaven). Dette utgjør om lag tre år med støtte for hver utgivelse. Debian LTS-teamet håndterer de siste (to) år med sikkerhetsstøtte slik at hver utgivelse drar nytte av minst 5 år med støtte, og slik at brukerne kan oppgradere fra versjon N til N + 2.