Von Pre-Alpha bis Release: die Entwicklungsphasen von Software

Warum Software in Phasen entsteht

Kaum ein Programm ist beim ersten Start fertig. Zwischen der ersten Idee und einer stabilen Version liegen Entwürfe, Umbauten und viele Tests. Die Phasenbegriffe helfen allen Beteiligten, Erwartungen abzustimmen: Entwickler wissen, wann neue Funktionen noch erlaubt sind, Testerinnen wissen, wonach sie suchen sollen, und Nutzer können einschätzen, ob sie ihre Daten schon einer Version anvertrauen wollen. Verbindlich definiert sind die Stufen nicht – jedes Team legt sie ein wenig anders aus.

Pre-Alpha: Bauplatz

In der Pre-Alpha-Phase entsteht das Grundgerüst. Anforderungen werden gesammelt, die Architektur wird skizziert, erste Prototypen zeigen, ob eine Idee überhaupt trägt. Vieles wird wieder verworfen. Öffentlich sind solche Stände selten, und wenn doch, dann meist als Demonstration eines einzelnen Kernmechanismus – bei Browser- und Onlinespielen etwa als erste spielbare Karte ohne Fortschritt und Speicherstand.

Alpha: alles da, nichts rund

Eine Alpha-Version enthält die meisten geplanten Funktionen, aber noch viele Fehler. Getestet wird vor allem intern, manchmal mit einem kleinen, eingeweihten Kreis. In dieser Phase darf sich noch viel ändern, auch an Datenformaten und Bedienung. Wer eine Alpha ausprobiert, sollte damit rechnen, dass Spielstände oder Einstellungen beim nächsten Update verloren gehen.

Beta: Feinschliff mit Publikum

Mit der Beta ist der Funktionsumfang weitgehend eingefroren („Feature Freeze“). Jetzt geht es um Fehler, Leistung und Bedienbarkeit. Eine geschlossene Beta richtet sich an ausgewählte Personen, eine offene Beta an alle Interessierten. Verwandt ist das Modell „Early Access“, bei dem zahlende Nutzer eine unfertige Version erhalten und die Entwicklung begleiten.

Release Candidate: fast fertig

Ein Release Candidate (RC) ist eine Version, die veröffentlicht werden könnte, wenn keine schweren Fehler mehr auftauchen. Neue Funktionen kommen jetzt nicht mehr hinzu. Findet sich ein gravierendes Problem, folgt nach der Korrektur ein weiterer Kandidat – RC1, RC2 und so weiter.

Stable, LTS und Wartung

Die fertige Version heißt je nach Umfeld „Stable“, „Final“ oder „General Availability“. Danach beginnt die Wartung: Fehlerkorrekturen und Sicherheitsupdates. Viele Projekte bieten zusätzlich Versionen mit Langzeitunterstützung (LTS) an, die über Jahre gepflegt werden. Für Server ist das oft die bessere Wahl, weil sich dort Stabilität mehr lohnt als die neueste Funktion – ein Grund, warum etwa Linux-Distributionen wie Debian ihre stabilen Versionen so lange pflegen (mehr dazu in den Linux-Server-Grundlagen).

Versionsnummern lesen: Semantic Versioning

Weit verbreitet ist das Schema Semantic Versioning mit drei Zahlen: MAJOR.MINOR.PATCH.

• MAJOR steigt, wenn sich etwas inkompatibel ändert – bestehende Nutzung kann brechen.
• MINOR steigt bei neuen Funktionen, die rückwärtskompatibel sind.
• PATCH steigt bei reinen Fehlerkorrekturen.

Vorabversionen bekommen einen Zusatz wie 2.0.0-alpha.1, 2.0.0-beta.3 oder 2.0.0-rc.1. Versionen mit führender Null (0.x) signalisieren, dass sich noch alles ändern darf.

Für eigene Projekte

Auch kleine Hobbyprojekte profitieren von klaren Stufen. Markiere Versionen in Git mit Tags, führe ein kurzes Änderungsprotokoll und schreibe dazu, ob eine Version experimentell ist. Wer ein Plugin oder ein Skript veröffentlicht, erspart sich damit viele Rückfragen. Wie ein eigenes Plugin entsteht, zeigt die Anleitung zum Minecraft-Plugin mit Paper; die Grundlagen fürs Programmieren findest du im Einsteiger-Beitrag zur ersten Programmiersprache.