ArubaOS and AOS-CX Release Descriptions
The following document describes releases “tags” or descriptions for ArubaOS/InstantOS (subsequently referred to as AOS) and AOS-CX software releases.
Visit the HPE Networking Support Portal
Active Release “Tags” or Descriptions
Short Supported Release (SSR)
- SSR are short lived releases where Aruba will introduce new features and new hardware, but we will not park any hardware (i.e., last major release supported).
- SSR release support period (e.g., Initial Release + n time) are AOS or AOS-CX specific.
- The End of Maintenance (EOM*) and End of Support (EOST) will be the same date.
*Note: The existing “End of Development” milestone is replaced with the “End of Maintenance” milestone.
Refer to https://www.arubanetworks.com/support-services/end-of-life-policy/ for the timing specifics.
Long Supported Release (LSR)
- LSR are long lived releases where Aruba will introduce new features, new hardware, and park hardware (i.e., last major release supported) as needed.
- LSRs would be maintained and supported for 5 years (i.e., Initial Release + 5 years) but with two phases and with minor differences between AOS and AOS-CX.
- Initial Release to End of Maintenance (EOM*): Bug and vulnerability patching with releases reducing in frequency over time.
- EOM to End of Support (EOST): Vulnerability patching on an as needed basis for High or Critical CVSS issues.
Refer to https://www.arubanetworks.com/support-services/end-of-life-policy/ for the timing specifics.
C-build
In rare instances, a c-build, or customer build, is used to signify a release created to rapidly address a specific customer need, i.e. a unique feature or function, a specific defect fix to address a unique customer environment or adoption of hardware into an “out of cycle” release. A c-build is used as a temporary bridge until the feature, function, fix or hardware can be adopted into a Standard Release. C-builds go through a rapid quality assurance and test cycle for a specific customer use case only. Aruba recommends adoption of c-builds only to address a very specific use case.
C-builds are not supported by the Aruba Technical Assistance Center and are managed directly by the Aruba Development team. Approval must be given by the Aruba Development team for customers to adopt a c-build. C-builds are not posted to the Aruba Support page. C-builds are “one off” builds and there is no defined patch or support policy.
Deprecated Release “Tags” or Descriptions
The following have been deprecated and will no longer be used for new software releases. This has been done to streamline operations between the wireless and wired portfolios.
Conservative Release (CR)
The Conservative Release tag signifies a release has been deployed in multiple customer production networks. Conservative Releases can be considered as the “gold standard” or “go to” releases within the Aruba WLAN portfolio. Aruba recommends the adoption of Conservative Releases in any customer’s production network.
Standard Release (SR)
The Standard Release tag signifies a release introducing significant new software features and/or hardware platforms. Any customer interested in benefiting from new software features or hardware platforms are encouraged to upgrade to a Standard Release. Standard Releases always complete a thorough quality assurance and test cycle before posting and becoming available to all customers. After adoption by multiple customers, Standard Releases may be “promoted” to Conservative Releases.
Technology Release
The Technology Release tag signifies the release introduces new software features and/or hardware platforms quickly addressing evolving market requirements. Technology Releases enable Aruba to address unique customer features, product demands or technology enhancements within a short time window. Any customers who desire to adopt these emerging use cases are encouraged to upgrade to Technology Releases. Technology Releases go through an abbreviated quality assurance and test cycle to ensure operation of the new capabilities, but do not go through a complete test cycle to test all known customer use cases as is done with a Standard Release.
The Technology release naming convention adheres to the following pattern [a.b.c.d-featurename] or [a.b.c.d-HWPlatform] where “a.b.c.d” signifies the base Aruba OS version and the featurename/HWPlatform name signifies the new capability being introduced in that particular release.
The support life cycle for Technology releases tend to be short and typically extends until the features merge into a future Standard Release. There is no defined patch and support cycle for Technology Releases.
General Availability (GA)
The General Availability tag was previously used to signify the release has been deployed in multiple customer production networks. The General Availability tag has been replaced by the Conservative Release tag, please see above.
Early Deployment (ED)
The Early Deployment tag was previously used to signify a release recently introducing significant new software features and/or hardware platforms. The Early Deployment tag has been replaced by the Standard Release tag, please see above.