Roadmap

Version 25.03 (2025 March)

• replace VLAs (required by MSVC)
• replace packing attributes (required by MSVC)
• improve PCI address comparisons
• enable/disable counters
• ena dynamic HRSS size
• ena asynchronous reset request from device
• enetc NXP driver version 4
• eqos NXP driver
• mlx5 probing optimization
• mlx5 FDB flows optimization
• mlx5 eCPRI matching with template API
• mlx5 ipool debuggability
• xsc Yunsilicon driver
• testpmd attach/detach on primary and secondary
• DTS config improvements
• DTS traffic generator improvements
• DTS configuration of VF
• DTS flow rules
• DTS single core performance test
• DTS cleanup after a test
• replace DTS linters with Ruff

Version 25.07 (2025 July)

Version 25.11 (2025 November)

Nice to have - Future

Cycle model

A typical release should be done after 4 months.

It is designed to allow DPDK to keep evolving at a rapid pace while giving enough opportunity to review, discuss and improve the contributions.

The merge window will open once the previous release is complete. First version of a new feature must be submitted before the proposal deadline. Features that miss this first period will be deferred until the next release.

Updated versions of patches (v2, v3, etc.) will be submitted to address comments. The new features must be properly reviewed, tested and accepted before the integration deadline. Otherwise, they will be postponed to the next releases.

At the end of the merge windows, the first release candidates are out.

The last period is approximately 1 month long and is dedicated to bug fixing.

Stable Releases

There is a documentation page describing the guidelines of the stable releases.

Stable point releases follow mainline releases.

After each -rc tag and after the final version, relevant bug fixes get backported by the stable maintainers into the respective branches in “bursts”.

Developers can provide stable-specific patches by sending them to stable@dpdk.org only (avoiding dev@dpdk.org). Further information on subject prefixes for this case is documented here.

After all the relevant bugfixes have been backported, regression tests are run, and if clear, the stable release is announced.

Typically a new stable release version follows a mainline release by 3-6 weeks, depending on the test results.