Diskussion:Entwicklungsstadium (Software)

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Entwicklungsstadium (Software)“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Zum Archiv

Wie wird ein Archiv angelegt?

Automatische Archivierung

Auf dieser Seite werden Abschnitte monatlich automatisch archiviert, deren jüngster Beitrag mehr als 100 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 3 Abschnitte.

Entwicklung beginnt früher u.a.

Dieser Artikel zeichnet die Entwicklungsstadien zu eng. Es müsste darauf hingewiesen werden, dass schon weit vor einer (Pre-)Alpha-Version Aktivitäten (mit 'Meilensteinen') liegen, die die Grundlagen für die Software legen/verkörpern. Ein ausdrücklicherer Verweis z.B. auf 'Vorgehensmodell' wäre angebracht.
Daneben: Nach welcher Quelle werden die Stadien genau so genannt? Andere Quellen könnten hier möglicherweise andere Begriffe nennen. Siehe auch Releasemanagement. --VÖRBY (Diskussion) 10:02, 30. Nov. 2017 (CET)

Überhaupt liest sich der Artikeltext sehr als POV/TF, z.B. unterhalb von 'Release' in 'Benennungen': Unklar, was Beta sei?? Nur Teile seien Beta - wo gibts denn sowas? Man sollte den Beleg-Baustein einstellen. --VÖRBY (Diskussion) 15:35, 30. Nov. 2017 (CET)

Das ist von mir. Ja, stimmt, dass die Quellenlage mau ist. Bitte einfach alles wieder löschen, oder, besser: bitte verbessere es! Das Problem war, dass Begriffe wie "Developer Release" und auch Early Access überhaupt nicht vorkamen, obwohl das eindeutig keine fertigen Versionen sind. Auch liest man bei manchen Programmen von einem Beta Build, bei anderen von einer Beta Version, und beim dritten Projekt von einem Beta Release (ersetze "Beta" durch "Developer", "Preview", "Alpha" usw.).

Mir wäre es sehr recht, wenn da jemand Verbesserungen vornimmt, der vom Fach ist und Quellen hat. Es ist jedoch auch richtig, dass es diese Begriffe gibt, dass man sie überall immer findet und dass man sie ergo auch hier erklären sollte, denn genau dazu ist die Wikipedia da.

Zu guter letzt: Endlich Feedback! Danke!

‣Andreas•⚖ 18:13, 30. Nov. 2017 (CET)

Ja, diese Situation gibts häufig in Wikipedia: Ein Artikel wird aus einer bestimmten, dem Autor bekannten Perspektive beschrieben, hier wohl für eine bestimmte Entwicklungsumgebung zutreffend. Aus anderen 'Blickwinkeln' sieht das oft anders aus. Zumindest sollte man vlt. ergänzen, nach welcher 'Schule' diese Objekte so genannt werden. Vielleicht sind die Texte auch zu lang, das Kapitel Betatest zu ausführlich für HIER - im Gegensatz zu anderen Stadien. Ich versuche mal, Einiges nach Betatest zu verschieben.

Naja, ohne Belege hier ist es auch bei Betatest weiterhin unbelegt. Außerdem wird ja auch Beta-Version hier her verlinkt und nicht nach Betatest. Und dass es einmal Version, einmal Release und dann wieder Build heißt, ist so. Da braucht man sich nur Software im allgemeinen anschauen. Beispiele sind ja im Text bereits aufgeführt, und die galt es zu erklären.

Ebenso wie die Begriffe Developer Release, Service Release, Public Beta oder Closed Beta und Early Access.

Ich hatte gerade einen Pre-Alpha Build zum Testen. Das war im Rahmen eines Early Access. Dieser Build hatte natürlich auch eine Versionsnummer.

Ich denke nicht, dass das alles nach Betatest verschoben werden sollte, da der Test ja nicht die Version, den Release oder den Build erklärt, sondern den Test.

Oder? ‣Andreas•⚖ 11:02, 1. Dez. 2017 (CET)

Vielleicht sollte man drastisch kürzen und dabei kurz aufzählen, welche Begriffe in der Praxis synonym verwendet werden, vlt. auch nur näherungsweise. Es sollte unterschieden werden zwischen dem, was den 'Betatest' (als Aktion) betrifft und was das 'Stadium' (als Zustand von 'Software') betrifft. Letzteres soll/will der Artikel beschreiben, 'Testen' sollte hier (wenn überhaupt) nur ganz kurz behandelt werden - mit Hauptartikelverweis(en), nur den Rest verschieben. Außerdem sollte unbedingt unterschieden werden zwischen der Versionierung (beliebig kleiner) Software-Teile (Module, Objekte etc., je nach Typ wie Quellcode, Objektcode, Makro ... eigene Versionen) und dem Stadium einer „Software“ als Gesamtheit; dies ist beim Betatest ja das Subjekt, nicht irgendwelche SW-'Futzel'. Übrigens: 'Open Beta' und 'Closed Beta' sind m.E. keine Differenzierungen für das Objekt (also im Stadium), sondern im TUN; getestet wird in beiden Fällen dasselbe, nämlich eine 'vollständige' ~Anwendung. Ja, das könnte viel Arbeit werden.  ;-) --VÖRBY (Diskussion) 12:46, 1. Dez. 2017 (CET)

Da bin ich bin bei, klingt gut. Jedoch ist die Version immer auch ein Produkt der Aktion. Die Beta-Version XY ist z.B. die aus der Closed Beta, die nächste Beta-Version dann jene aus der Open Beta. Das Insider-Programm von Microsoft ist so ein Beispiel. Da gab es normale Versionsnummern oder Builds, die allerdings exklusiv für Insider-Teilnehmer verfügbar waren, und somit auch als Insider-Build bezeichnet wurden. Beispiele hier und hier. Vondaher sollte der Artikel sehr wohl die Besonderheit von diesen Beta-Versionen beschreiben, wenn auch nur kurz.

‣Andreas•⚖ 13:03, 1. Dez. 2017 (CET)

Nachtrag: hier und hier sind deutsche Beispiele.

Und nochmals zum Großen und Ganzen, in Richtung WP:OMA: jemand liest von diesen Builds, Releases und Versionen, und will sich dann informieren. Daher muss das auch irgendwo erklärt werden, was das eigentlich ist. Normiert ist es natürlich nicht, aber existent dennoch. ‣Andreas•⚖ 13:07, 1. Dez. 2017 (CET)

@SW-Futzel: Wenn ein Teil eines Programms so verändert wird, dass das gesamte Programm dann nicht mehr stabil läuft, dann ist das gesamte Programm keine stabile Version mehr. Das ist sicher logisch und Teil einer Weiterentwicklung. Schon oft gesehen und gelesen. So gibt es beispielsweise bei 7-Zip eine als Stabil ausgewiesene Version, und nachfolgende Versionen wurden eben weiterentwickelt, doch die Änderungen wollen erst mal getestet werden. Irgendwann ist der Entwickler zufrienden und mach eine der neueren Versionen zur ab dann stabilen Version. Das ist doch genau das, was Entwicklungsstabium (Software) zusammenfast, nicht? Daher ist es egal, welche Teile verändert wurden: dann ist immer die gesamte Version nicht mehr "stable" oder "final release", sondern wieder mitten im Entwicklungsprozess und sozusagen eine Beta-Version, wenn öffentlich (z.B. 7-Zip) auch für willige Anwender.

Darum steht das so drinnen. Aber offenbar war es nicht so ganz verständlich, wodurch es wohl umformuliert, umgeschrieben, gekürzt, besser erklärt (verlängert) oder sonst verändert werden sollte. ‣Andreas•⚖ 13:20, 1. Dez. 2017 (CET)

Ich habe an dem Artikel vor 10 Jahren gebastelt, damals hat man die Einzelbelege eher nur bei strittigen Themen angegeben. Seid deshalb bitte fair. (Heute belege ich jeden Satz.) Wie auch immer, der Artikel ist sicherlich nicht in allen Facetten komplett, die Begriffe werden sicherlich auch anders verstanden da nicht standardisiert, aber etwas wirklich Falsches erkenne ich nicht. Wer sich berufen fühlt, der kann es besser machen.--Avron (Diskussion) 19:50, 1. Dez. 2017 (CET)

Ja, und ich kann nicht sagen, dass da was falsches stehen würde. Und um das klar zu stellen: nur der Abschnitt Benennungen stammt von mir. Der Rest war schon da und war gut.

Den Abschnitt empfand ich als wichtig, da ich immer wieder auf diese Begriffe stieß:

• * Build/Version/Release
• experimental, unstable, testing, Preview, stable, final *
• Besonderheit Nightly Build (gutes Beispiel: CyanogenMod bzw. LineageOS hat haufenweise Nightly Builds, die eher in die Kategorie "ohne Garantie" fallen, meist aber stabil sind...)
• Developer Release, Developer Preview, Public Beta, Insider Preview, etc...
• Internal Build und Private Build ist mir beim Lesen untergekommen: intern testen Firmen oft ihre Software, und die ist dann eben "interal" oder "private"
• Maintenance oder Service * (siehe u.a. hier)
• Early Access fehlte komplett, doch sind manche Programme/Spiele eben als solche Early Access Version oder Release gekennzeichnet

Ich weiß, der Rahmen ist weit gefasst, aber eine Pre-Alpha, Alpha-, Beta- oder Final Version kann eben auch eine der oben genannten sein, daher muss man das irgendwo erklären.

‣Andreas•⚖ 23:48, 1. Dez. 2017 (CET)

Offene Details

Hallo, ich habe mal angefangen, zusammenzustellen, was mir so am Artikel grundsätzlich 'sauer aufstößt':

• 'Software' sind nicht nur ausführbare Programme, z.B. gehört auch dazu die Dokumentation - die i.d.R. schon sehr viel früher als Anforderungen, Pflichtenheft etc. existiert. Einleitung konkretisieren und auf Software i.S. 'ausführbar' reduziert definieren.
• Dagegen beschreibt der Artikel lediglich ausführbare Software - und wohl auch nur im Zusammenhang mit dem Testen, großteils sogar nur i.Z. mit Betatests - und dazu m.E. Zu ausführlich, teils auch redundant. Das Lemma ist aber allgemeingültiger.
• Eine 'Veröffentlichung' ist (übersetzt) eine 'Freigabe'. Das heißt, das ist eine Tätigkeit, V. ist also ein substantiviertes Verb. Es sollte am Anfang des Abschnitts 'Benennungen' erläutert werden, dass es hier als Bezeichnung für eine (freigegebene; 'released') Software-PAKET (mit einer bestimmten Versions-/Releasenummer) verwendet wird. Oder besser: Das Tun und das Objekt wird mit unterschiedlichen Ausdrücken benannt. In Releasemanagement#Releaseerstellung wird 'Veröffentlichung' korrekt benutzt; siehe dort.
• Das betrifft auch mehrere andere Bezeichnungen: Build z.B. heißt 'bauen, errichten ...' (ebenfalls ein Verb), während es hier als Ergebnis benutzt wird. Das bedarf dringend der Klärung. Auch 'Version' ist i.e.S. kein Softwarepaket, sondern dessen lfd. Nummer. 'Build' sei das 'Kompilieren eines Quelltexts'. Das ist begrifflich falsch, es müsste 'compilierter Quelltext' heißen - was wiederum als sprachliche Übersetzung unkorrekt wäre.
• Möglichst Synonyme ergänzen, um klarzustellen, wie das in anderen Umgebungen oder nach anderen Normen genannt wird, z.B. lt. ITIL (DML), PRINCE2 o.ä. Standards. Im Artikel werden Unterschiede mehrfach 'von Projekt zu Projekt' o.ä. genannt; ebenfalls irreführend und unkorrekt.
• In Siehe Beta-Version / Teilkomponenten: Aussage ist m.E. ein Widerspruch: Betatests werden für die gesamte Anwendung aufgesetzt. Ob das ein erstmaliger Test ist oder einer wg. (meist gravierenden) Änderungen, ist egal. Die jeweilige SW ist also als Gesamtheit eine'Beta-Version', Einzelteile daraus haben jeweils ihre eigenen ~Versionsnummern.
• Diese Diskrepenz in den Meinung rührt auch daher, dass nicht definiert ist, ob die 'Veröffentlichung' (...) nur für einzelne Komponenten gilt oder immer zu einer 'Anwendung'.
• Software, die ohne Betatest in Einsatz geht, ist keine Beta-Version, sondern einfach ein neues 'Release'. Auf diese optionale Existenz in der Stadium-Kette hinweisen. 'Betatest' ist im Übrigen nur eine Testart unter vielen anderen. 'Alphatests' sind der Überbegriff für alle Tests (und Testarten), die vorher (i.d.R. durch Entwickler) erfolgen.
• Auch kommt es wohl gar nicht so selten vor, dass die Software einfach am Ende des Projekts in die PROD übergeben wird - ohne den ganzen 'Zinnober' mit den verschiedenen Releases.

Können wir diesbezüglich mal Klarheit schaffen?--VÖRBY (Diskussion) 13:15, 2. Dez. 2017 (CET); ergänzt: --VÖRBY (Diskussion) 10:22, 4. Dez. 2017 (CET) ergänzt: --VÖRBY (Diskussion) 12:50, 6. Dez. 2017 (CET)

Ja, Klarheit wäre schön. Ich habe bis jetzt keine eindeutige Quelle finden können, die diese Klarheit herstellen würde.

Klar ist nur, dass es "Release 7.7" von X11 gibt, dass es also X11R7.7 heißt. Dann gibt es natürlich auch Versionen, also der Xserver selbst ist Version 1.12.2 in R7.7, bzw. 1.9.3 in R7.6. (Quellen: Release 7.7 bzw. Changelog (Versionen)) – neuere Versionen der einzelnen Module sind so gesehen Updates nach dem Release.

Bei vielen Programmen (Software) gibt es Release Canditates, etwa bei Windows 7 RC aka "Release Candidate" (Quelle). Release und Release Candidates sind natürlich auch Versionen und Builds. Aber der Zusammenhang muss erklärt werden: was ist was? Ist ein RC eine Beta-Version oder nicht? Warum ist es ein RC? Und was ist eine Preview Release? (Apple bezeichnet(e) es eher PR als RC...) Und was soll bitte das sein: Developer Release, Developer Preview, Insider Preview, etc...?

Ja, das ist viel Durcheinander - weil wohl Begriffe aus unterschiedlichen Praxisumgebungenbenutzt werden. Besser: als Synonyme bezeichnen. --VÖRBY (Diskussion) 17:03, 2. Dez. 2017 (CET)

Weil es jedesmal anders heißt, ist es eben "von Projekt zu Projekt" unterschiedlich. Wie es dem Hersteller/Herausgeber gerade einfällt oder in einer Roadmap festgelegt wurde. Aber erklären sollte man es dann eben, zumal ein Wissensuchender ja am ehesten in einer Enzyklopädie anfängt, etwas darüber zu erfahren.

Das sind keine 'Projekte', sondern es kommt von unterschiedlichen Entwicklungsumgebungen/Herstellern etc. --VÖRBY (Diskussion) 17:03, 2. Dez. 2017 (CET)

Außerdem haben solche Vorversionen direkten Einfluss auf die Softwareentwicklung und sind eindeutig ein Stadium derselben. Daher passt diese Information in diesen Artikel und nicht etwa in den Artikel Versionsnummer.

Man kann nicht das Ergebnis jeder neuen Compilierung HIER als Version/Stadium behandeln! Ich denke, dass "Entwicklungsstadium" etwas anderes ist. Zumindest muss man unterschiedliche Ebenen auseinanderhalten und das auch klar so beschreiben. --VÖRBY (Diskussion) 17:03, 2. Dez. 2017 (CET)

Zu Release, Version, Build: das sind alles Hauptwörter. Ein Release ist eine Veröffentlichung. Eine Version wie im deutschen auch eine Version. Ein Build ist aber eben der fertige Build, nicht die Tätigkeit "to build", obwohl man es gleich schreibt.

Wir sollten die Objekte dann vielleicht immer in kursiv setzen, um sie vom Tun zu unterscheiden. Und am Anfang auf diese IT-Denglisch-Ausdrücke hinweisen. 'Veröffentlichung' ist in Deutsch immer eine Tätigkeit! Und dass ein solcher Build das 'Kompilieren eines Quelltexts' wäre, ist definitiv falsch. --VÖRBY (Diskussion) 17:03, 2. Dez. 2017 (CET)

Der Xserver hat eine Releasenummer, eine Versionsnummer und ein Build-Datum. So kann man eine Unterscheidung vom groben zum Feinen vornehmen: welche X11-Release? Aha, R7.7. Welche Version des Xserver? Aha, 1.19.5. Aber welcher Build? Mein /var/log/Xorg.0.log enthält folgendes:

X.Org X Server 1.19.5
Release Date: 2017-10-12
[    13.313] X Protocol Version 11, Revision 0
[    13.313] Build Operating System: Linux 4.9.0-4-amd64 x86_64 Debian
[    13.313] Current Operating System: Linux MacMini 4.13.0-1-amd64 #1 SMP Debian 4.13.13-1 (2017-11-16) x86_64
[    13.313] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.13.0-1-amd64 root=/dev/mapper/macmini--ssd-debian ro quiet
[    13.313] Build Date: 16 October 2017  12:28:38PM
[    13.313] xorg-server 2:1.19.5-1 (https://www.debian.org/support)

Der Build dient ebenso der Unterscheidung wie die Version, denn ein Build kann stabil sein und funktionieren, ein anderer eben nicht. Das hängt aber direkt mit der Software-Entwicklung und Veröffentlichung zusammen, da ja Build-Nummern auch zu Veröffentlichung ansich gleicher Versionen dienen (können).

Ein Build, wenn er z.B. im Zusammenhang mit einem Betatest genannt wird, kann sich mit seinen VersNrn nicht auf Einzelteile der Software beziehen. Das sind zwei unterschiedliche Paar Schuhe. --VÖRBY (Diskussion) 17:03, 2. Dez. 2017 (CET)

Der Linux-Kernel dagegen hat eine fortlaufende Build-Nummer und per uname zusätzlich ein Build-Datum. Andere Programme haben eventuell nur eine Build-Nummer.

Du siehst, dass das wohl immer Umgebungsabhängig so ist. Passt aber so nicht in ein Lexikon. --VÖRBY (Diskussion) 17:03, 2. Dez. 2017 (CET)

Ich schreibe nur, was da draussen ist – und was erklärt werden sollte. Ich habe auch schon oft Quellen gelesen, die ganz andere Informationen hergeben und einen sehr eingeschränkten Blickwinkel haben, was dazu führt, dass z.B. ein Release Candidate gar nicht erklärt wird (in der Quelle gänzlich fehlt), oder dass Builds nicht wichtig seien. Das stimmt aber nicht, weil es ganz offenbar von Projekt zu Projekt extrem unterschiedlich ist, was davon wichtig ist.

‣Andreas•⚖ 15:42, 2. Dez. 2017 (CET)

Nachtrag: Was natürlich derzeit auch noch fehlt, sind die Milestones (etwa hier bei Firebird vor der Umbenennung in Firefox). ‣Andreas•⚖ 15:51, 2. Dez. 2017 (CET)

Siehe Anmerkungen in Deinem Text in Kleiner Schrift. Ich denke, wir haben hier das Problem, sich in der IT aus unterschiedlichen Historien etc. entwickelten Ausdrücke (ja da gibts viel Durcheinander) hier im Lexikon verständlich und vor Allem allgemeingültig zu beschreiben. --VÖRBY (Diskussion) 17:03, 2. Dez. 2017 (CET)

Agreed.

Das Entwicklungsstadium ist natürlich ein theoretischer Begriff. Eine Veröffentlichung als Tätigkeit einerseits ist aber nicht das Veröffentlichte (aka Release) auf der anderen Seite. Ein "Release Candidate" ist eine Version, die veröffentlicht wird, um einen letzten öffentlichen Betatest durchzuführen und um einen Eindruck auf das (fast) fertige Produkt zu geben, nicht mehr und nicht weniger.

Eine Version als Identifikationsmerkmal hat einerseits eine Versionsnummer, andererseits eine Buildnummer/-datum, und zuletzt bzw. eigentlich zuallererst einen Veröffentlichungsnamen. Windows 95 SR1 aka Windows 95 Service Release 1 entspricht Version 4.00.950 A. Interessanter schon bei Windows 95 Service Release 2.1 – es gibt die Versionen 4.03.1212 B bis 4.03.1214 B (Quelle). Hier ist also der Zweck der Veröffentlichung im Namen: Service Release. Einmal veröffentlicht (als Tätigkeit) bleibt es aber das Produkt (oder Software-Entwicklungs-Projekt) unter demselben Namen, nämlich in diesem Beispiel Windows 95 SR2.1 4.03.1214 B.

Und was ist ein Build? Man kann ein und dieselbe Version unterschiedlich kompilieren, etwa mit anderen Compilern oder Compiler-Optionen oder anders Linken etc. Das wäre dann ein anderer Build desselben Quelltextes, also die gleiche Version und daher indentisch im Quelltext, aber doch anderes in binärer Form und unter Umständen der eine Build etwas schneller als der andere, oder etwas kompatibler mit unterschiedlicher Hardware, oder aber stabil versus instabil. Was sonst wäre ein Build in diesem Sinne? Siehe auch Nightly Build.

‣Andreas•⚖ 21:14, 2. Dez. 2017 (CET)

Entwurf für Neutextung

Die Diskussion verläuft wieder so wie das bei WP immer ist: Argumente werden genannt, auf sie wird aber nicht wirklich eingegangen, es gibt immer wieder Missverständnisse. Ich versuchs mal mit dem folgenden Entwurf:

Begriffe im Kontext 'Entwicklungsstadium' (für Programmkomponenten)

Definition in der Einleitung: Ein Entwicklungsstadium ist in der Softwaretechnik der Fertigstellungszustand, den ein zu erstellendes Softwareprodukt zu einem bestimmten Zeitpunkt erreicht hat oder erreichen soll. Die für ein Projekt relevanten/geplanten Stadien werden im Rahmen des Projektmanagements zeitpunktbezogen und inhaltlich festgelegt, basierend auf dem für das Projekt gewählten Vorgehensmodell, seinen seinen Aktivitäten und Meilensteinen oder aufgrund von Vorgaben in herstellerspezifischen Methodenkonzepten und Entwicklungsumgebungen. Meist bezieht sich der Begriff Entwicklungsstadium im engeren Sinn auf ausführbare Software, d. h. auf lauffähige Programme, die im Rahmen von Releasemanagement-Prozessen zum Testen oder an ihre Benutzer bereitgestellt werden.

In erweitertem Sinn ergeben sich unterschiedliche Entwicklungsstadien für Software im gesamten Projektverlauf, wo auch in konzeptionellen Projektphasen Ergebnisse entstehen, die bestimmten Meilensteinen (‚Entwicklungsstadien‘) zugeordnet sind. Beispiel siehe . Am Ende jedes Stadiums werden die definierten Projektergebnisse in das nachfolgende Stadium zur Bearbeitung übergeleitet.

Der Abschluss von Entwicklungsstadien für Softwarekomponenten wird in der Projektpraxis unterschiedlich gehandhabt: In kleineren Projekten wie beispielsweise bei der Softwarewartung wird die fertige Software oft erst komplett am Projektende zur Produktion übergeben; es sind keine Zwischenversionen vorgesehen. In anderen Fällen werden mehrere Stadien konkret benannt und behandelt. Als Mischform aus beiden entstehen Entwicklungsstadien situationsbezogen.

(=== Zweck / Unterschiede ===)

Die Zielsetzung für die Festlegung mehrerer Entwicklungsstatien ist im Allgemeinen, im Projektverlauf Fixpunkte mit definierten Reifegraden zu erreichen, um die anschließenden Aktivitäten sicher(er) bearbeiten zu können. Häufig werden unterschiedliche Entwicklungsstadien beim Softwaretest praktiziert, um in nachgelagerten Teststufen/Testarten z. B. Funktionsdetails überprüfen zu können, die auf bereits im vorhergehenden Stadium getesteten Funktionalitäten aufsetzen.

Unterschiede zwischen den einzelnen Software-Entwicklungsstadien können zum Beispiel folgende sein – um für den jeweils angegebenen Freigabezweck verwendet zu werden:

• Manche Funktionen sind noch nicht realisiert; für bestimmte Vorbereitungstests.
• ... oder sind nur in einfacher Form (ohne Spezialfälle) realisiert; ebenfalls für erste/frühe Tests.
• Die Software wurde im bisherigen Stadium nur durch bestimmte Testarten (wie Alphatests) überprüft; z.B. zur Weitergabe für Betatests.
• Die Komponenten enthalten für noch fehlende Funktionsteile noch Hilfsroutinen (z.B. Stubs oder Driver); zum Testen von Unterprogrammen.
• Die Anwendung wird zur Übernahme in eine spezielle System- oder Testumgebung bereitgestellt und ggf. zielsystemspezifisch adaptiert; z.B. zur Durchführung von Produktionstests oder Lasttests.
• In der Anwendung sind Hilfsroutinen enthalten, die das Testen und die Dokumentation von Fehlerfällen unterstützen; für öffentliche Tester.
• Stadiumbezogene Übergaben enthalten entweder die ganze Anwendung oder nur einzelne Komponenten zur (nachträglichen) Installation.
• Die Anwendung ist vollständig einsatzbereit (letztes Stadium); zur finalen Übergabe in die Produktionsumgebung.

(=== Beispiele für Entwicklungsstadien ===)

Entwicklungsstadien und Bezeichnungen für Softwarereleases können zum Beispiel sein:

pre-Alpha → Alpha → Beta → Release Candidate → Release.

In anderen Fällen praktiziert ein Hersteller Releasebezeichnungen wie die folgenden:

CLOSED → INAL STABLE → FINAL → CURRENT BUILD → SCEDULED.

Hier sollten/können die Bezeichnungen jeweils erläutert werden - aus dem alten Text. Auch Synonyme hier nennen.

Dabei ergeben sich zwischen den Haupt-Stadien in der Softwareentwicklung beliebig viele Zwischenversionen, zum Beispiel aus der Behebung gemeldeter/erkannter Programmfehler.

(=== Glossar im Kontext ===)

Manche im Zusammenhang mit Entwicklungsstadien benutzten Termini (siehe Liste) werden umgangssprachlich für unterschiedliche Begriffsebenen benutzt. Sie können stehen für:

• Die abstrakte Benennung eines Entwicklungsstadiums; ‚produktive Freigabe‘ lt. Vorgehensmodell
• Die stadium- oder versionsbezogene Softwarekomponente; ‚Release 3a‘ der Anwendung ABC
• Die Tätigkeit der Freigabe; ‚Übergabe‘, ‚Veröffentlichung‘

Wenn die Termini im Text unzweideutig benannt wären, könnte man das hier löschen!

• Beispiele: Freigabe, Veröffentlichung, Release, Version (major, minor ...)

Hier sonstige Ausdrücke erläutern - die nicht 'Stadium' SIND.

Ansonsten sollten die o.g. Punkte sukzessive in den Texten irgendwie berücksichtigt werden. Ggf. inkl. Belegen. --VÖRBY (Diskussion) 10:22, 4. Dez. 2017 (CET)
ergänzt: --VÖRBY (Diskussion) 17:33, 4. Dez. 2017 (CET) vorbereitet zur Übernahme: --VÖRBY (Diskussion) 19:16, 8. Dez. 2017 (CET)

Diskussion dazu

Du kennst dich offenbar weit besser aus als ich. Vondaher: ja. Machen.

Mein Zugang war leider ein völlig anderer: ich kam über Beta-Version zum Artikel. Offenbar ist das aber eine Themenverfehlung. Vielleicht sollte alles diesbezüglich tatsächlich in einen eigenen Artikel oder zur Versionsnummer. Allerdings ist auch letzerer offenbar eine Themenverfehlung, da er sehr Software-bezogen ist und nicht allgemein Versionsnummern behandelt (beispielsweise haben auch technische Teile jeder Größe eine Versionsnummer, u.a. auch sogar ganze Flugzeuge...).

Eine dritte Meinung wäre da noch sinnvoll.

‣Andreas•⚖ 13:08, 4. Dez. 2017 (CET)

Man spürt, dass der Artikel irgendwie sehr mit 'Betatest' zusammenhängt. Dabei ist das Lemma aber wesentlich allgemeiner. Man hätte die relevanten Aussagen z.B. auch bei 'Vorgehensmodell' bzw. 'Meilenstein' oder bei 'Releasemanagement' kurz erläutern können. Aber ich versuchs mal weiter, zumindest in der Einleitung und mit wesentlichen Kapiteln wie 'Unterschiede / Zwecke'. Danke für die Mitarbeit; bleibe bitte mir "am Ball". --VÖRBY (Diskussion) 13:20, 4. Dez. 2017 (CET)

Die o.a. Entwurfstexte würde ich zunächst mal als Einleitung einstellen. Danach sollte man die ausführlichen, sich i.W. auf Betatests beziehenden Aussagen kürzen. Feedback bitte. --VÖRBY (Diskussion) 12:50, 6. Dez. 2017 (CET)

Es liest sich sehr schwer, weil es mMn versucht, allgemein gehalten zu bleiben. So ähnlich habe ich es in meinem Abschnitt Benennungen ja auch gemacht. Ich kann ansatzweise, teilweise oder ganz verstehen, was da steht, je nach Teilinhalt.

Die einzige Frage, die sich mir gerade stellt, ist die: hast du Quellen dafür und welche sind das? Kannst du die noch verlinken? Denn sonst kann ich nur sagen "ja, wird schon passen" und mit den Schultern zucken. Wenn ich allerdings selbst in der Quelle nachlesen könnte, hätte ich eine bessere Basis für fundierteres (wenn schon nicht 100% qualifiziertes) Feedback. ‣Andreas•⚖ 18:27, 7. Dez. 2017 (CET)

Danke. Ich kann über den Text nochmal drübergehen. Bezüglich 'Belegen' geht es mir zunächst auch so wie @Avron: Das kenne ich so aus dem Projektmanagement/Releasemanagement/Testmanagement. Ich habe dazu noch keine Quellen gesucht. Wie schon gesagt: Diese (Deine?) Entwicklungsstadien sind methodisch nichts anderes als 'Meilensteine' im Vorgehen(smodell), und technisch nicht anderes als Software-Freigaben/Releases. In wievielen 'Portionen' diese SW-Freigaben erfolgen und wie man dabei die einzelnen 'Stadien' benennt, ist m.E. nebensächlich und bei Weitem nirgends genormt, wenn, dann sicher unterschiedlich. Ich kann aber nochmal googeln. --VÖRBY (Diskussion) 21:08, 7. Dez. 2017 (CET)

Du hast mein vollstes Verständnis. Es ist oft ein sehr schwerer weg, gerade wegen WP:TF. Belegen könnte ich z.B. nur die Namen der Releases, eben z.B. "Beta" oder "Release Canditate" oder "Maintenance Version" (dt. Serviceversion?). Aber die Theorie dahinter kann ich nicht belegen. Das wäre aber zumindest im Ansatz wichtig. Vielleicht hilft da Google mit der Bücher-Suche weiter. (DuckDuckGo oder ixquick können leider keine Bücher durchsuchen...)

Der Text könnte noch ein wenig allgemein-verständlicher werden (WP:OMA), ja. Wohin würdest du dann den aktuellen Inhalt hingeben? (Stichwort: "Beta-Version"...) Und dann gibt es da ja noch ein Durcheinander bei einigen der anderen verlinkten Artikel, z.B. auch bei Version (Software) und Versionsnummer.

‣Andreas•⚖ 21:20, 7. Dez. 2017 (CET)

Hab hier ein Beispiel für ein Buch gefunden... ‣Andreas•⚖ 21:23, 7. Dez. 2017 (CET)

Ja, Belege suche ich noch. Vorläufig würde ich nur die o.a. Entwurfstexte i.W. in und nach der Einleitung einstellen. Den Rest im Artikel sollte man anschließend 'wikifizieren', i.W. kürzen. Vor allem klingt das alles so, als wenn diese Stadien und ihre Bezeichnungen absolut "in Stein gemeißelt", also allgemeingültig wären. Englisch-Deutsch kommt da noch dazu; siehe Maintenance = Wartung = Service? Schaun mer mal!--VÖRBY (Diskussion) 11:29, 8. Dez. 2017 (CET)

Das war eine Unachtsamkeit von mir, Maintenance ist natürlich Wartung, also eine Wartungsversion. Ohne es ganz genau zu wissen denke ich jedoch schon, dass es keinen wesentlichen Unterschied zwischen einer Service Release und einer Maintenance Release (bzw. -Version oder -Build) gibt, außer eben den Namen. ‣Andreas•⚖ 00:56, 9. Dez. 2017 (CET)

Ich habe den Entwurfstext in einer nochmal angepassten Form im Artikel eingestellt. Ab Kapitel Benennungen sollte noch eine Überarbeitung erfolgen, am besten eine Kürzung. Siehe auch Begriffe wie 'Veröffentlichung': Das klingt wie eine 'Tätigkeit', wird aber für 'stadiumspezifische Softwareversion' verwendet, und ist so nirgends erläutert. Den begriffsbezogenen/ebenenspezifischen Hinweis aus dem Entwurf habe ich nicht eingestellt, der Artikeltext sollte aber schon sauber und für jede OMA verständlich sein.--VÖRBY (Diskussion) 12:41, 11. Dez. 2017 (CET)

In den Hauptabschnitten ist m.E. noch Vieles beschrieben, das zT so nicht stimmt (siehe Build/Compiler; heute von mir geändert) oder zweifelhafte Bezeichnungen trägt oder redundant ist. M.E. ist vieles in diesem Detaillierungsgrad überflüssig. Ich will aber an fremden Texten nicht weiter rumbasteln. --VÖRBY (Diskussion) 17:23, 19. Dez. 2017 (CET)

Du kannst dies aber gerne tun. Wenn es nötig ist, warum solltest du dann nicht an fremden Texten herumbasteln. Gerade wenn es um den Detailierungsgrad geht, dann bist du herzlichst eingeladen, den Text entsprechend zu kürzen oder einfacher zu formulieren. Wenn es mir nicht passt, stelle ich es sicher zur Diskussion oder ändere es, mit entsprechender Begründung, wieder um.

Ich bin mit Teilen des Textes auch nicht zufrieden, da man derzeit zu vieles redundant vorfindet. Allerdings ist es sehr schwer, das, was man sagen will, in wenigen Sätzen klar zu sagen. Außerdem kommt man dann oft vom 100sten ins 1000ste, und man kann sich leicht verirren... (und somit verwirren :-)).

‣Andreas•⚖ 22:05, 19. Dez. 2017 (CET)

RTM und GM?

Ich bin immer noch nicht ganz zufrieden mit dem Begriffen. Der Artikel stellt es so dar, als gäbe es grundsätzlich RTM (Release-to-Manufacturing) oder GM (Golden Master). Das ist aber nicht so. Bei Microsoft (Windows) hieß es immer RTM, bei Apple immer GM (früher einmal, heute, mit dem Vertrieb über das Internet als Download eher auch nicht mehr...).^Quelle

Die Frage lautet: ist der Artikel damit zu Microsoft- bzw. Apple-lastig?

Es gibt so viel unterschiedliche Software, und nicht alle (vermutlich eher die wenigsten) bezeichnen das dann als RTM oder GM, sondern eher als Release oder Final. Wie gesagt, es ist eben dem Hersteller überlassen, wie er die einzelnen Stadien benennen will.

Meinungen dazu?

‣Andreas•⚖ 12:14, 17. Dez. 2017 (CET)

Nochwas: Apple gibts noch die Golden-Master-Versionen, aber nur an Entwickler.^Quelle Und die sind zwar fast identisch mit der öffentlichen finalen Version, die alle Apple-Geräte gratis erhalten (wenn der Benutzer das Upgrade durchführt), aber eben nicht ganz: „The only difference between the latest golden master release candidate for developers and public beta of OS X Yosemite versus the final version is a minor change in build numbers.“^Quelle

Für mich sieht das ganze so aus: früher hat Apple einen Golden Master gemacht (vermutlich, und das ist jetzt wirklich nur eine ganz ganz große Vermutung von mir: weil man es anfänglich auf eine goldene CD-R gebrannt hat und in die CD-ROM-Fabrik verschickt hat, wo der Golden Master dann vervielfältigt wurde zur Verkaufs-CD-Version) – heute fällt diese Notwendigkeit durch den App Store und das Online-Upgrade weg, für Developer (und das ist dann soetwas wie eine Closed Beta, also nur an einen eingeschränkten Kunden-/Interessenskreis) gibt es aber weiterhin Developer Previews (DP1, DP2, etc...) und schließlich den Golden Master (machmal auch in Form eines GM1, GM2, etc...). Damit können die Entwickler ihre Software auf der kommenden Betriebssystemversion testen und gegebenenfalls anpassen, damit eventuell eine (immer noch/wieder) funktionierende Version davon zum Zeitpunkt der Verfügbarkeit der finalen Version des neuen Betriebssystems zeitgleich/zeitnah ebenfalls gleich zur Verfügung steht.

‣Andreas•⚖ 12:28, 17. Dez. 2017 (CET)

Und nochwas: RTM – obwohl von Microsoft (oder war es umgekehrt?!?) – scheint ein vielfach etablierter Begriff zu sein, da er oft im Zusammenhang mit Softwareentwicklung und deren Stadien auftaucht.^Quelle ABER ist es deswegen nicht dennoch Microsoft-lastig? (Das heißt, sollte es sich bestätigen, dass RTM wirklich von Microsoft eingeführt wurde.)

Die Quintessenz: die Begriffe RTM und GM müssen natürlich auftauchen, aber sie sollten eben nur als Beispiele dienen, wie es benannt sein kann, aber eben nicht, dass es so bezeichnet wird, denn das wäre falsch, da es eben nur auf Microsoft oder Apple zutrifft (und ein paar andere, die die Begriffe übernommen haben).

‣Andreas•⚖ 12:34, 17. Dez. 2017 (CET)

Man sieht, dass solche Begriffsbildungen sehr projekt- oder auch herstellerabhängig sind. Man sollte sie deshalb zwar (als herstellerbezogene Synonyme) erwähnen, aber nicht mit den Details (wie hier diskutiert) behandeln. Das geht über das Lemma hinaus. Nochmal: Hier sollte einfach beschrieben sein, was ein Entwicklungsstadium IST (wofür es gut ist usw.), plus signifikanten Beispielen. Darüberhinaus kann es nicht schaden, alternative Bezeichnungen solcher Stadien zu erwähnen - um die Verbindung zur (allermeistens herstellerbezogenen) Realität zu gewährleisten. Die alten Abschnitte sind in diesem Sinn nach wie vor eine Themaverfehlung. Zumal es nicht nur Standardsoftware gibt; auch bei Indiv-SW werden ES praktiziert - und auch in nicht "SW-Produkt"-bezogenen Projektphasen der Softwaretechnik.

Übrigens: Wo soll das mit RTM und GM stehen?? --VÖRBY (Diskussion) 09:57, 18. Dez. 2017 (CET)

Wie meinst du das, wo soll es stehen? Hier: Entwicklungsstadium (Software)#Release. Oder meinst du, wo es stehen sollte? Keine Ahnung, aber es macht schon Sinn, bekannte Benennungen für Entwicklungsstadien zu nennen. Vor allem dann, wenn nach Beta-Version, Release-to-Manufacturing etc. gesucht wird, was Otto-Normal-Wikipedia-Wissenssuchender unter Umständen auch tut. ‣Andreas•⚖ 21:27, 18. Dez. 2017 (CET)

Ich meinte Deinen ersten Satz oben in diesem Abschnitt. Klar sollten alle möglichen Bezeichnungen/Synonyme erwähnt werden - aber nicht so 'absolut' ("dass das ist immer so ist") wie es derzeit erscheint. --VÖRBY (Diskussion) 09:21, 19. Dez. 2017 (CET)

Beispiel Firefox

Der Webbrowser Mozilla Firefox erscheint in sechswöchigen Abständen in drei verschiedenen Versionen: der experimentellen Version Firefox Nigthly (pre-alpha), der experimentellen Version "Firefox Developer Edition", der größtenteils stabilen Version Firefox Beta und der stabilen Version Firefox[6][7],. Für mich sind das auf Grund gebräuchlicher Anwendung deutscher Semantik vier Versionen. Ich vermute mal, dass der experimentellen Version Firefox Nigthly (pre-alpha) und der experimentellen Version "Firefox Developer Edition" das gleiche meinen sollen, aber die Interpunktion und der Satzbau stellen die beiden Elemente auf die gleiche Ebene wie die nachfolgenden, somit muss man hier vier Versionen lesen. Kann das mal jemand mit Fachkenntnis herausklamüsern? --Ariser (Diskussion) 14:11, 20. Jun. 2018 (CEST)