Release Note

A release provides a stable snapshot of the codebase and is the formal announcement to the community of new features, completed improvements, and changes that may affect users (including breaking changes).

Note

Triton-distributed-ascend has not yet published a stable release. The project is built from source; see Build from Source. The tables below record the versioning and branch policy, and will be filled in as releases are published.

Release Compatibility Matrix

The following is the release compatibility matrix for Triton-distributed-ascend versions:

Triton-distributed-ascend Version

Python Version

Hardware Platform

Hardware Product

unreleased

>=3.8

Ascend NPU

A2/A3, Ascend 950

Release Schedule

The following is the Triton-distributed-ascend release schedule. Patch releases are optional.

Major Version

Release Branch Cut Date

Release Date

Patch Release Date

—

—

—

—

Release Highlights

Release highlights are added here as versions are published. Each entry should summarize the key features, known limitations, and any migration steps required.

Unreleased

Current development state

The project currently targets Atlas A2/A3 and Ascend 950, and is built from source against CANN 9.1.0 or later.

Key Features

  1. Distributed communication primitives

    • AllReduce, AllGather, ReduceScatter, and All2All

  2. Computation-communication overlap

    • Overlapped execution of computation and communication

  3. AscendNPU IR-based compiler optimizations

    • Optimizations that target Ascend hardware features directly

  4. Python-friendly interfaces

    • Python APIs that integrate into existing deep learning frameworks

Known Limitations

  1. Distribution: No binary distribution is published; installation is from source only

  2. Hardware coverage: Validated on Atlas A2 and Ascend 950

Release Strategy

Version Numbering

Triton-distributed-ascend follows the PEP 440 versioning specification: vMAJOR.MINOR.PATCH[rcN][.postN]

  • MAJOR.MINOR: Tracks the Triton version the project is based on

  • PATCH: Used for bug fixes or improvements at the MAJOR.MINOR level

  • rcN: Release candidates, published as needed for early community testing and feedback

  • postN: Post-releases, published as needed to fix issues in stable releases

Branch Strategy

  • The master branch is the latest development branch

  • A release branch is created for each release (for example, release/3.2.2)

  • Feature development should be done in a fork of the repository and merged via pull request

Maintenance Branches and Lifecycle

Maintenance branch statuses:

  • Active: Continuously accepts bug fixes, feature improvements, and security patches

  • Maintenance: Only accepts critical bug fixes and security patches; no feature improvements are released

  • End of Life: No fixes are accepted; maintenance of the branch has stopped

Branch

Status

Release

End of Maintenance

master

Active

/

/

release/3.2.2

Active

—

/

Release Cycle

  • Stable releases: Released according to the project’s version cadence

  • rc releases: Released for early user testing ahead of a stable release

  • post releases: Published as needed to fix issues in existing stable releases

Release Timeline

Date

Event

—

—

Version Compatibility Matrix

Each published release records the dependency versions it was built and validated against:

Triton-distributed-ascend

Python

CANN

PyTorch

torch_npu

unreleased

>=3.8

9.1.0

2.7.1

2.7.1.post8

The values in the unreleased row are the versions pinned in requirements.txt and stated in Installation.