# Triton 3.2.0 reached PyPI with five Linux compiler wheels Triton 3.2.0 appeared on PyPI on January 22, 2025, with five Linux x86-64 wheels for CPython 3.9 through 3.13 and a matching promotion tag. Canonical: https://rangoon.ai/insights/archive-triton-3-2-pypi-promotion-january-2025/ Author: Rangoon Editorial (https://rangoon.ai/insights/editorial/) Published: 2026-10-24 Updated: 2026-10-24 Event date: 2025-01-22 Tags: [inference runtime](https://rangoon.ai/insights/tags/inference-runtime/), [AI inference](https://rangoon.ai/insights/tags/ai-inference/), [open source](https://rangoon.ai/insights/tags/open-source/), [Infrastructure](https://rangoon.ai/insights/tags/infrastructure/) Source note: Historical reporting: the version-specific PyPI record gives January 22, 2025 as the release date and dates the five wheel uploads to that day. The Triton repository tag separately records readiness for PyPI promotion. A source tag and an uploaded distribution are different records. No October branch-cut history is asserted, and current package metadata is not treated as a complete January release announcement. Image: compiler package to kernel path. Original Rangoon explanatory diagram: Source boundary: dated primary release reporting; original editorial analysis. No vendor interface, photograph, measurement result, or endorsement implied. ## Key takeaways - The dated PyPI record establishes January 22 package publication, while the GitHub tag records readiness to promote the 3.2.x release. - The version-specific file list contains five Linux x86-64 wheels covering CPython 3.9 through 3.13; that is a packaging scope, not a universal device-support claim. - The public records identify a concrete compiler dependency but contain no application benchmark that establishes an inference-speed gain. ## The package registry supplies the publication date [source 1](https://pypi.org/project/triton/3.2.0/) [source 2](https://github.com/triton-lang/triton/releases/tag/v3.2.0) Triton 3.2.0 was published on PyPI on January 22, 2025. The version-specific registry record gives that release date and lists five wheel files uploaded on the same day. Separately, the project repository has a v3.2.0 tag whose message says the 3.2.x release was ready for promotion to PyPI. Reading both records resolves a small but important historical distinction: a maintainer can mark source as ready before a distribution exists for a package installer. Here, the registry supplies evidence of actual uploaded files. The tag supplies the project-side promotion context. Neither record is a model announcement or an application-performance result. ## Five wheels defined a concrete Python and operating-system surface [source 1](https://pypi.org/project/triton/3.2.0/) The 3.2.0 file list contains Linux x86-64 wheels for CPython 3.9, 3.10, 3.11, 3.12 and 3.13. Each filename identifies its interpreter and platform tags, so the publication is more precise than a general claim that a new compiler version was available. The visible records establish those specific distribution artifacts; they do not establish a matching Windows, macOS, ARM or arbitrary Python build. This distinction matters when a higher-level framework resolves a compiler dependency automatically. An environment can request the same version number yet have a different compatible-file selection, or no matching file, because its interpreter or platform differs from the published wheel tags. ## The tag and registry answered different dependency questions [source 1](https://pypi.org/project/triton/3.2.0/) [source 2](https://github.com/triton-lang/triton/releases/tag/v3.2.0) The repository tag names version 3.2.0 and describes enabling promotion for the 3.2.x line. The package record identifies the corresponding version in the distribution registry and exposes file-specific hashes. Together they give an engineer two useful references: a project-side source revision and the concrete wheel an installer can retrieve. They are not interchangeable identifiers. A source checkout may be built with a different toolchain or local changes, while a wheel is a particular binary artifact. Keeping the tag, selected filename and its digest together makes the dependency record more informative than writing only Triton 3.2 in a build note. ## This was a package-publication milestone, with a narrow evidence boundary [source 1](https://pypi.org/project/triton/3.2.0/) [source 2](https://github.com/triton-lang/triton/releases/tag/v3.2.0) The dated uploads make this a verifiable release event even though the tag message contains little feature detail. The article therefore reports package availability and the visible distribution scope rather than inventing a kernel-feature list or a planned branch-cut chronology. The registry and tag do not publish an end-to-end inference benchmark for this release. They also do not show which Triton version a downstream framework actually selected, which GPU kernels ran or how a model behaved. Those are different observations. The January record remains useful for reconstructing an environment: it names the version, the publication day and the specific binary files that could have been selected, without converting those facts into a claim about every workload. ## Sources 1. [PyPI: Triton 3.2.0 release files and upload dates](https://pypi.org/project/triton/3.2.0/) 2. [Triton GitHub: v3.2.0 PyPI-promotion tag](https://github.com/triton-lang/triton/releases/tag/v3.2.0) ## Related reading - [ONNX Runtime 1.21 added GenAI pipeline changes while removing older paths](https://rangoon.ai/insights/archive-onnx-runtime-1-21-genai-march-2025/) - [SGLang 0.5.1 added cache and scheduling work to its serving release](https://rangoon.ai/insights/archive-sglang-0-5-1-hicache-august-2025/) - [PyTorch 2.6 joined compiler changes with a Linux packaging transition](https://rangoon.ai/insights/archive-pytorch-2-6-compiler-packaging-january-2025/) ## More information - [Documentation index](https://rangoon.ai/llms.txt) - [AI access and policies](https://rangoon.ai/ai/) - [Source repository](https://github.com/hypler-dev/rangoon)