ArubaOS und AOS-CX-Versionsbeschreibungen

Das folgende Dokument beschreibt „Tags“ bzw. Beschreibungen für ArubaOS/InstantOS (im Folgenden „AOS“) und AOS-CX-Softwareversionen.
HPE Networking-Support-Portal besuchen

Aktive „Tags“ oder Beschreibungen für Versionen

Short Supported Release (SSR)

  • Bei SSRs handelt es sich um kurzlebige Versionen, bei denen Aruba neue Funktionen und Hardware einführt, aber keine Hardware parkt (also mit der letzten unterstützten Hauptversion).
  • Der Zeitraum für die Unterstützung von SSR-Versionen (z. B. Erstversion + n Zeit) ist spezifisch für AOS bzw. AOS-CX.
  • Das Wartungsende entspricht dem Datum des Supportendes.

* Hinweis: Der bestehende Meilenstein „Entwicklungsende“ wird durch den Meilenstein „Wartungsende“ ersetzt.

Die genauen Zeitangaben finden Sie unter https://www.arubanetworks.com/support-services/end-of-life-policy/.

Long Supported Release (LSR)

  • LSRs sind langlebige Versionen, bei denen Aruba bei Bedarf neue Funktionen und neue sowie geparkte Hardware einführt (also mit der letzten unterstützten Hauptversion).
  • Sie umfassen Wartung und Unterstützung für 5 Jahre (also Erstversion + 5 Jahre), allerdings in zwei Phasen und mit geringfügigen Unterschieden bei AOS und AOS-CX.
  • Erstversion bis Wartungsende: Fehler- und Schwachstellen-Patching, wobei die Häufigkeit der Versionsveröffentlichungen im Laufe der Zeit abnimmt.
  • Wartungsende bis Supportende: Schwachstellen-Patching für hohe oder kritische CVSS-Probleme.

Die genauen Zeitangaben finden Sie unter https://www.arubanetworks.com/support-services/end-of-life-policy/.

C-Build

In seltenen Fällen wird eine Version als „C-Build“ oder „Customer Build“ gekennzeichnet, mit der schnell eine spezifische Kundenanforderung eingeführt wird, d. h. ein einzigartiges Feature oder eine Funktion, eine spezifische Problembehebung für eine bestimmte Kundenumgebung oder die Aufnahme von Hardware in eine außerzyklische Version. Mit einem C-Build erfolgt eine temporäre Überbrückung, bis das Feature, die Funktion, die Fehlerbehebung oder die Hardware in ein Standard Release übernommen werden kann. C-Builds durchlaufen eine schnelle Qualitätssicherung und einen Testzyklus, der nur einen bestimmten Anwendungsfall prüft. Aruba empfiehlt die Einführung von C-Builds nur, um einen sehr spezifischen Anwendungsfall zu ermöglichen.

C-Builds werden vom Aruba Technical Assistance Center nicht unterstützt und direkt durch das Aruba-Entwicklungsteam verwaltet. Der Einsatz eines C-Build bei Kunden muss durch das Entwicklungsteam genehmigt werden. C-Builds werden nicht auf der Aruba-Support-Seite veröffentlicht. Sie sind einmalige Builds, für die es keine festgelegte Patch- oder Supportrichtlinie gibt.

Überholte „Tags“ oder Beschreibungen für Versionen

Folgendes wurde überholt und wird für neue Softwareversionen nicht mehr verwendet, um die Abläufe zwischen den Portfolios drahtloser und kabelgebundener Angebote zu optimieren.

Conservative Release (CR)

Das Tag „Conservative Release“ kennzeichnet eine Version, die in mehreren Produktionsnetzwerken von Kunden bereitgestellt wurde. Conservative Releases können als die besten und bevorzugten Versionen des Aruba-Portfolios betrachtet werden. Aruba empfiehlt den Einsatz von Conservative Releases in allen Produktionsnetzwerken der Kunden.

Standard Release (SR)

Mit dem Tag „Standard Release“ sind Versionen gekennzeichnet, die signifikante, neue Softwarefunktionen und/oder Hardwareplattformen einführen. Kunden, die davon profitieren möchten, sollten ein Upgrade auf ein Standard Release durchführen. Standard Releases durchlaufen immer eine strenge Qualitätssicherung und einen Testzyklus, bevor sie veröffentlicht werden und für alle Kunden verfügbar sind. Nach der Einführung bei mehreren Kunden können Standard Releases zu Conservative Releases werden.

Technology Release

Mit dem Tag „Technology Release“ sind Versionen gekennzeichnet, die neue Softwarefunktionen und/oder Hardwareplattformen einführen, um schnell auf Veränderungen der Marktanforderungen zu reagieren. So kann Aruba kurzfristig einzigartige Kundenfunktionen, Produktanforderungen oder technologische Verbesserungen einführen. Alle Kunden, die solche neuen Anwendungsfälle einführen möchten, sollten ein Upgrade auf Technology Releases durchführen. Diese durchlaufen eine verkürzte Qualitätssicherung und einen Testzyklus, um die Funktionsfähigkeit der neuen Optionen sicherzustellen. Sie durchlaufen jedoch keinen vollständigen Testzyklus, in dem alle bekannten Anwendungsfälle von Kunden getestet werden, wie dies bei einem Standard Release der Fall ist.

Die Namenskonvention für Technology Releases folgt dem Muster [a.b.c.d-Featurename] oder [a.b.c.d-HWPlattform], wobei „a.b.c.d“ die zugrunde liegende Aruba OS-Version kennzeichnet und „Featurename“ bzw. „HWPlattform“ die neue Funktion angibt, die mit der Version eingeführt wird.

Der Supportlebenszyklus von Technology Releases ist tendenziell eher kurz, in der Regel bis zur Aufnahme der Funktionen in ein zukünftiges Standard Release. Für Technology Releases ist kein Patch- oder Supportzyklus definiert.

General Availability (GA)

Das Tag „General Availability“ wurde bisher verwendet, um Versionen zu kennzeichnen, die in mehreren Produktionsnetzwerken von Kunden bereitgestellt wurden. Das Tag „General Availability“ wurde durch das oben beschriebene Tag „Conservative Release“ ersetzt.

Early Deployment (ED)

Das Tag „Early Deployment“ wurde bisher verwendet, um eine Version zu kennzeichnen, mit der signifikante, neue Softwarefunktionen und/oder Hardwareplattformen eingeführt wurden. Das Tag „Early Deployment“ wurde durch das oben beschriebene Tag „Standard Release“ ersetzt.