pick-25 content-sync KNW-2086 updated

Author: SilkePaintner

src/onprem/de/cmk_versions.asciidoc

@@ -1,5 +1,5 @@
 // -*- coding: utf-8 -*-
-// IGNORE [ ] 0b1 0b2
+// IGNORE [ ] 0b1 0b2 Produktlebenszykluses
 // NONASCII
 include::global_attr.adoc[]
 = {CMK}-Versionen
@@ -22,10 +22,10 @@ Die Entwicklung findet auf dem Hauptentwicklungszweig (_Master_) statt.
 
 Nach etwa 9–12 Monaten beginnt die Beta-Phase.
 Für diese wird ein Zweig abgespalten, auf dem die stabile Version finalisiert und später gepflegt wird.
-Auf dem Hauptzweig beginnt dann schon wieder die Vorbereitung für den nächsten Zyklus.
+Auf dem Hauptentwicklungszweig beginnt dann schon wieder die Vorbereitung für den nächsten Zyklus.
 
 Sowohl auf dem Hauptentwicklungszweig als auch auf dem stabilen Zweig gibt es tägliche Zwischenversionen (_Daily Builds_),
-welche Ihnen einen schnellen Zugriff auf neue Features oder Bug Fixes bieten.
+welche Ihnen einen schnellen Zugriff auf neue Features und Fehlerbehebungen (Bug Fixes) bieten.
 Grafisch dargestellt sieht das Ganze zum Beispiel für die Version {v24} etwa so aus:
 
 image::cmk_versions_development_diagram.png[width=80%]
@@ -42,7 +42,7 @@ Auch hier im Handbuch begegnen Sie daher verschiedenen Varianten des Begriffs _V
 === Tagesversionen vom Master (Daily Builds)
 
 {cee-only}
-Auf dem Entwicklungszweig (in der Versionskontrolle Git heißt dieser „master“) wird die Zukunft von {CMK} entwickelt.
+Auf dem Hauptentwicklungszweig (in der Versionskontrolle Git heißt dieser „master“) wird die Zukunft von {CMK} entwickelt.
 Damit Entwickler, Anwender und andere Interessierte sich jederzeit ein Bild vom aktuellen Stand der Software machen können,
 wird jeden Tag zwischen 0:00 und 6:00 Uhr mitteleuropäischer Zeit ein Installationspaket für alle unterstützten Linux-Distributionen gebaut.
 Diese Pakete werden auch _Daily Builds_, _Git Snapshots_ oder _Entwicklerversionen_ genannt und stellen den exakten Stand der Softwareentwicklung zu Beginn eines jeden Tages dar.
@@ -61,7 +61,7 @@ Dies gilt insbesondere dann, wenn Sie diese Features selbst bei uns in Auftrag g
 === Beta-Versionen
 
 Das Release einer neuen stabilen Version (z.B. {current-major}) beginnt mit einer Beta-Phase.
-Um alle Fehler zu beheben und die Software tauglich für die Produktion zu machen, wird dazu ein _stabiler Zweig_ abgespalten, welcher nur noch Fehlerbehebungen enthält.
+Um alle Fehler zu beheben und die Software tauglich für die Produktion zu machen, wird dazu ein _stabiler Zweig_ abgespalten, welcher nur noch durch Fehlerbehebungen ergänzt wird.
 Auf dem Hauptzweig geht parallel die Entwicklung der Features für die Zukunft weiter.
 
 Auf dem stabilen Zweig wird nun eine Serie von Beta-Versionen mit einem kleinen `b` im Namen veröffentlicht -- (z.B. {current-major}b1, {current-major}b2, usw.).
@@ -76,7 +76,7 @@ Da die Software nun von mehr Benutzern eingesetzt wird, werden jetzt in der Rege
 Diese werden in einer Reihe von *Patch-Versionen*, manchmal auch als Patch Releases bezeichnet, behoben ({current-major}p1, {current-major}p2, usw.).
 Die Abstände dieser Patch-Versionen sind anfangs recht kurz (etwa eine Woche) und später viel länger (einige Monate).
 
-Zusätzlich zum Master werden auch auf dem stabilen Zweig Tagesversionen veröffentlicht, die Ihnen Bug Fixes zeitnah bereitstellen.
+Zusätzlich zum Master werden auch auf dem stabilen Zweig Tagesversionen veröffentlicht, die Ihnen Fehlerbehebungen zeitnah bereitstellen.
 Diese tragen den Namen des Zweigs plus das Datum, z.B. {current-major}-2025.03.30.
 
 Sie können diese Versionen produktiv einsetzen, solange Sie Folgendes beachten:
@@ -124,11 +124,11 @@ Die stabile Version wird aktiv gepflegt, d.h. mit Patch-Versionen versorgt.
 Wie lange das passiert, hängt davon ab, wann die Folgeversion freigegeben wird und dadurch zur neuen stabilen Version wird.
 Die Regel ab der Version {v16} lautet:
 Die aktive Pflege endet für eine Version 6 Monate nach Freigabe der neuen Version.
-Da für die stabile Version die Folgeversion noch nicht freigegeben ist, dient der geplante Freigabetermin zur Festlegung des Produkt-Lifecycle. 
+Da zu Beginn einer stabilen Version die Folgeversion noch nicht freigegeben ist, dient der geplante Freigabetermin zur Festlegung des Produktlebenszykluses. 
 
 Damit werden für 6 Monate zwei Versionen parallel mit Patch-Versionen bedient:
 die stabile Version (_stable_) und die Vorgängerversion (_oldstable_).
-Eine Übersicht über den xref:support_periods[Produkt-Lifecycle] finden Sie am Ende dieses Artikels.
+Eine Übersicht über den xref:support_periods[Produktlebenszyklus] finden Sie am Ende dieses Artikels.
 
 
 [#passive_maintenance]
@@ -139,14 +139,14 @@ Nach Ablauf der aktiven Pflege geht der stabile Zweig in die passive Pflege übe
 Während dieser Zeit beheben wir Fehler nur noch im Auftrag von Kunden, die uns diese im Rahmen eines Support-Vertrags in Form von Support-Tickets melden.
 
 Es gibt jedoch keine Garantie dafür, dass alles, was Benutzer als Fehler ansehen könnten, behoben wird.
-Auch werden nicht alle Bug Fixes bis in die ältesten Versionen portiert.
-Das betrifft insbesondere Features, die als veraltet (_deprecated_) gelten -- diese werden im Allgemeinen keine Bug Fixes erhalten.
+Auch werden nicht alle Fehlerbehebungen bis in die ältesten Versionen portiert.
+Das betrifft insbesondere Features, die als veraltet (_deprecated_) gelten -- diese werden im Allgemeinen keine Fehlerbehebungen erhalten.
 
-Bug Fixes während der passiven Pflege lösen weitere Patch-Versionen aus, von denen dann natürlich auch diejenigen Anwender profitieren, welche keinen Support-Vertrag haben.
+Fehlerbehebungen während der passiven Pflege lösen weitere Patch-Versionen aus, von denen dann natürlich auch diejenigen Anwender profitieren, welche keinen Support-Vertrag haben.
 
 
 [#support_periods]
-=== Produkt-Lifecycle der stabilen Versionen
+=== Produktlebenszyklus der stabilen Versionen
 
 {cee-only}
 Ob Ihre Version also noch gepflegt wird und wann sie ihr Lebensende (_End of Life_) erreicht hat oder erreichen wird, können Sie der nachfolgenden Tabelle entnehmen:

src/onprem/en/cmk_versions.asciidoc

@@ -22,10 +22,10 @@ This development takes place on the main development branch (_master_).
 
 The beta phase begins after about nine to twelve months.
 A branch is split off for this, on which the new stable version will be finalized and later maintained.
-On the main branch the preparation for the next cycle will then begin.
+On the main development branch the preparation for the next cycle will then begin.
 
 As well as on the main development branch, daily intermediate versions (_daily builds_) are also created on the stable branch
-– which offer access to new features or bug fixes.
+– which offer access to new features and bug fixes.
 A graphic representation of the whole process for the {v24} version looks somewhat like the illustration below:
 
 image::cmk_versions_development_diagram.png[width=80%]
@@ -42,7 +42,7 @@ You will therefore also encounter different variants of the term _version_ here
 === Daily builds from the master
 
 {cee-only}
-On the development branch (in the Git's version control this is referred to as the ‘master’), {CMK}'s future is being developed.
+On the main development branch (in the Git's version control this is referred to as the ‘master’), {CMK}'s future is being developed.
 So that developers, users and other interested parties can at any time get an impression of the current state of the software,
 every day between 0:00 and 6:00 Middle European Time an installations package for all supported Linux distribution versions will be created.
 These packages are called _daily builds_, _Git snapshots_ or _developer versions_, and they represent the exact state of the software's development at the start of every day.
@@ -60,7 +60,7 @@ This is especially applicable if you yourself have commissioned us to develop th
 === Beta versions
 
 The release of a new stable version, (e.g. {current-major}), begins with a beta phase.
-In order to correct all errors, and to make the software production ready, an additional _stable branch_ containing only error corrections will be split off.
+In order to correct all errors, and to make the software ready for production, a _stable branch_ is created, to which only bug fixes are added.
 Development of features for future versions continues in parallel on the main branch.
 
 On the stable branch a series of beta versions – identified by a lowercase `b` in their names – will be published, (e.g., {current-major}b1, {current-major}b2, etc.).
@@ -123,7 +123,7 @@ We will actively maintain this stable version with patch versions.
 How long this happens depends on when the follow-up version is released and thus becomes the new stable version.
 The rule as of version {v16} is:
 The active maintenance ends for a version 6 months after the release of the new version.
-Since for the stable version the follow-up version has not yet been released, the planned release date serves to determine the product lifecycle.
+Since at the release of the stable version the follow-up version has not yet been released, the planned release date serves to determine the product lifecycle.
 
 This means that two versions are served in parallel with patch versions for 6 months:
 the stable version and the previous (_oldstable_) version.