Nexthop NOS is powered by SONiC (Software for Open Networking in the Cloud), an open-source project under Linux Foundation. This policy defines the software lifecycle for Nexthop NOS release trains, ensuring a predictable schedule for maintenance, feature availability, and end-of-life (EOL) planning.
Alignment with SONiC Community
Nexthop NOS major release trains are rooted in a community SONiC release branch (basic_sonic_branch). However, once an upstream release is branched off master train in community, the corresponding Nexthop NOS release train will start being prepared for shipping a generally available (GA) release. In this Nexthop NOS train we have flexibility to enable any required features and bug fixes across SONiC, Switch Abstraction Interface (SAI), SDK, required FRR version, into a corresponding NOS release to meet planned Roadmap and for any Time-to-market purposes for customers.
Lifecycle Framework
Each major release train of Nexthop NOS is supported for a total of 30 months from the date of first General Availability (GA) release as depicted below with an example. Every release train will have a few cycles of feature releases while in the active feature development phase, where new features are introduced and then the train will transition to maintenance which means only bug fixes are brought in on a regular basis. Maintenance releases will be denoted by ‘M’ in the software release naming.
Feature Development Phase (Months 1 – 6)
The first six months of a release train focus on delivering active enhancements and features.
- Scope: New features, protocol extensions, and new platform introsupport
- Release Identifier: Releases with no special identifiers are feature releases
- Customer impact: Customers should expect changes to CLI commands, new features, support for new platforms and updated capabilities
Maintenance Phase (Months 7 – 24)
At the start of the seventh month, the release train will enter a feature-freeze state called active maintenance which means only bug fixes are released on a regular basis to ensure production stability. Maintenance releases will be denoted by ‘M’ in the software release naming.
- Scope: Bug fixes, security hardening, and stability improvements. No new features or hardware platforms are added
- Release Identifier: Denoted by the “M” suffix (e.g., 202505.6M).
- Customer Impact: These are low-risk releases stabilized for production environments
Support Only Phase (Months 24 – 30)
Once a release reaches the 24-month mark, it goes into Support Only Phase. There will continue to be TAC support during this phase but no proactive bug fixes or M releases are posted. To avail certain bug fixes, software upgrades will be required.
End of Support (Months 30+)
Once a release exceeds the 30-month mark, it is considered End of Support. Customers are required to migrate to a newer supported release train.
Versioning
Through the lifecycle, the numbering function follows the format below:
Version Format: [base_sonic_branch].[Major].[Minor][Phase (for M)]
base_sonic_branch: Identifies the specific SONiC community branch (e.g., 202505) upon which the Nexthop NOS release is constructed.
Major: Denotes the functional baseline. Increments in this value during the first 6 months signify the addition of new features or hardware support.
Minor: Represents an exception service release based on the major feature release to deliver specific security patches or a one off critical product patch on top of the previous feature release.
Phase M (Maintenance): Indicates that the feature set is frozen, and the release train is focused on further improving stability.
