Standard releases

This page explains how standard nRF Connect SDK releases are structured, documented, and maintained. For detailed information about version strings, see Versions and revisions. For information about Git tags, see Git tags.

Release purpose

The purpose of a release of the nRF Connect SDK from Nordic Semiconductor is to provide a stable, validated, and versioned software baseline for products that use Nordic Semiconductor’s nRF platforms.

Each release serves the following purposes:

Provide a consistent development baseline

Includes a known-good combination of Zephyr and Nordic modules, drivers, stacks, and tools.

Ensure stability and quality

Integrates and validates features through regression testing, hardware validation, and system-level verification.

Enable product development

Gives you a reliable foundation for commercial products without requiring you to track unstable mainline changes.

Provide conformance-ready software

Aligns the SDK with relevant standards, such as Bluetooth®, Thread, Matter, and security requirements, where applicable.

Bundle features and fixes

Groups new features, improvements, bug fixes, and security fixes into predictable releases.

Manage platform evolution

Introduces new capabilities while maintaining backward compatibility and controlled deprecation.

Support long-term maintenance

Supports long-term support and maintenance branches for products that require long-term stability.

Each nRF Connect SDK release turns continuous development into a predictable, tested, and supportable software snapshot for product-grade use.

Release frequency

Release tags for the nRF Connect SDK are in the sdk-nrf repository. The nRF Connect SDK follows a time-based release cadence with two or three releases a year. This schedule provides regular, validated releases that are qualified for standards conformance without overly frequent updates.

Release versioning

Release versioning defines the type of each nRF Connect SDK release tag. For more information about release versioning, see Versions and revisions. For information about Git tag formats, see Git tags.

Release tags follow semantic versioning and use the following categories:

Standard releases

  • Preview tag

  • Major release tag

  • Minor release tag

  • Maintenance release or patch tag

Long-term support (LTS)

  • Long-term supported release tag

  • Long-term supported patch tag

For more information about LTS releases, see Long-term support releases.

Pre-release

  • Release candidate (RC) tags are also used as internal tags before releases.

Release documentation

The following documents describe each nRF Connect SDK release:

  • Release notes Provide the primary entry point for understanding what changed in a release. They include key highlights, major feature additions, important bug fixes, security updates, and notable subsystem changes.

  • Migration notes Help you upgrade to a new nRF Connect SDK version. They describe API changes, removed or deprecated features, Kconfig and DTS updates, and required project changes.

  • Software maturity levels Defines the lifecycle state of nRF Connect SDK features and components. It helps you assess stability, API consistency, and suitability for commercial use.

  • Known issues Provides a consolidated list of validated issues for a specific nRF Connect SDK release. When possible, it includes workarounds, mitigation steps, and references to patches or future fixes.

Release dependency management

nRF Connect SDK releases normally align with stable Zephyr releases. A release can occasionally use a Zephyr *.99 development release if required content is not yet available in a stable Zephyr release. In that case, the release branch is updated to the corresponding stable Zephyr tag when it becomes available.

This alignment lets you build products on well-tested Zephyr baselines with the nRF Connect SDK layered on top. It improves quality assurance and enables consistent delivery of future bug fixes and security updates where applicable.

Deprecation policy

In the sdk-nrf repository, features, modules, samples, APIs, or configuration options can be deprecated as the SDK evolves. Deprecations are communicated in official release notes and marked in the codebase with Kconfig options or equivalent build-time indicators.

A deprecated feature remains available for a defined transition period, typically at least two subsequent nRF Connect SDK releases. This gives you time to evaluate alternatives, adapt applications, and migrate to supported replacements.

After the deprecation period, the feature is removed from the SDK. This keeps the codebase maintainable and aligned with the current architecture while minimizing long-term technical debt.

This policy follows the principles of the Zephyr Project deprecation policy. The alignment provides consistency with upstream practices and predictable lifecycle management for users who build on the nRF Connect SDK. For more information about API deprecation in the nRF Connect SDK, see API deprecation.

Updating to a new release

Use the latest nRF Connect SDK LTS tag when long-term stability is required. For more information about LTS releases, see Long-term support releases.

Before you update, review the Release notes and the relevant Migration notes. If a product requires devices or features that are not available in the latest LTS release, you can start product development with a newer nRF Connect SDK release.

For installation instructions, see Installing the nRF Connect SDK. For repository and tool update instructions, see Updating the repositories.