No release for v2.2.0

[GaetanLepage]

Although Pypi reports 2.2.0 being available, there is no corresponding tag on the git repository. Could you please create one ?

Context: updating triton in the nixpkgs repository.

Thanks !

[jlebar]

There is a branch.

On Tue, Apr 2, 2024 at 12:16 AM Gaétan Lepage @.***> wrote:

Although Pypi reports 2.2.0 being available, there is no corresponding tag on the git repository. Could you please create one ?

Context: updating triton in the nixpkgs repository.

Thanks !

— Reply to this email directly, view it on GitHub https://github.com/openai/triton/issues/3535, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABEZB34SL7T3TU4UYOQ45LY3JLNJAVCNFSM6AAAAABFSZ7FXGVHI2DSMVQWIX3LMV43ASLTON2WKOZSGIYTSNZUGIZDAMA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[GaetanLepage]

There is a branch.

Thank you for the hint. Would it still be feasible to create a tag for this release ? We tend to directly fetch packages upstream sources from the git repositories using a release tag.

Thank you for your help and consideration.

[dfyz]

@GaetanLepage

Would it still be feasible to create a tag for this release ?

JFYI: the tag is not likely to help here, since the commit history for the release branches (including release/2.2.x) appears to have been modified retroactively, which broke the build (see issue #3525).

In particular, the commit you have for the 2.2 release in the nixpkgs PR is no longer part of this repository:

The replacement commit is 0149bf70042efb998fc7a1ea30ed99e3a0f75053, which is affected by issue #3525 as well.

[GaetanLepage]

Ok this makes sense. Thank you for this explanation ! Feel free to close this issue then.

[dfyz]

Feel free to close this issue then.

Uh, sorry, I worded that confusingly. :/ Having a v2.2.0 tag would be very valuable, exactly because it's supposed to be immutable (as opposed to a release branch). All I was saying was that, as of right now, there is no valid commit that can be tagged with v2.2.0. Hopefully the situation in issue #3525 will be resolved somehow, and then a tag can be made.

(and just to clarify, I'm not a Triton developer/contributor, so all of the above is just my personal opinion)

[GaetanLepage]

Got it !

[jlebar]

We definitely should not be modifying history on the release branch, yikes. I'll raise this with Phil; maybe the release branch is not protected from force pushes.

WRT making a tag, I'll ask the folks who maintain the release branch.

[jlebar]

@shunting314 how would you feel about making release tags? Given that we messed up and force-pushed to the release branch, it sort of feels like we ought to make proper tags so they're immutable.

[ptillet]

Yes, I am very sorry for screwing things up over the weekend. I think it can be reverted though!

[ptillet]

the history of the release branch should be back to normal now. Can you confirm that it works? Sorry again for the disruption.

[dfyz]

Can you confirm that it works?

It does, thank you! I just closed issue #3525.

Regarding this issue: given that the branch history is restored, I think it is now possible to tag 0e7b97bd47fc4beb21ae960a516cd9a7ae9bc060 (the original untagged commit used in the draft nixpkgs PR and the current HEAD of release/2.2.x) as v2.2.0, and call it a day?

[Qubitium]

This is a very confusing thread to follow. So what it is the exact commit for triton 2.2.0 released to pip? tip of https://github.com/openai/triton/tree/release/2.2.x or a commit on the branch but not the tip? Thanks.

[danpetry]

It would also be great to get a tag for v2.3.0 at the same time. Currently there's a release branch - however, I was wondering whether it would be possible to please tag the commit relating to the pypi release? This is to support the CUDA variant of PyTorch in Anaconda's main channel - i.e., to distribute v2.3.0 of Triton as a conda package. I can see the commit used by PyTorch for their release, however, this seems to not be on a branch any more. A tagged commit would be preferable from a SHA (even though a SHA is less mutable, we still should be able to claim that we're releasing a certain upstream version)

[danpetry]

Ideally, a proper github source release would be best

[GaetanLepage]

Hello, Could the 2.2.0 tag been made please ? It would allow to close this issue and for us to package it correctly.

Thank you very much !

[danpetry]

The 2.3.0 one as well please 🙏

[apmorton]

+1 to tagging releases please - many downstream ecosystems depend on tags for automated updates - like conda-forge.

Without them, maintainers don't get notified that new upstream releases are available.

https://github.com/conda-forge/triton-feedstock

[GaetanLepage]

@jlebar sorry to bother you with this issue but this prevents us (nixpkgs maintainers, and apparently conda's too) from shipping the latest triton updates to our users.

Thank you very much for your consideration

[jlebar]

cc @bertmaher

[jlebar]

Meta folks are handling the release mechanics, maybe Bert can help.

[iamthebot]

I'm taking a stab at updating the conda-forge feedstock for triton. But without these tagged commits, this is going to be a super manual process going forward.

Am I understanding correctly that this commit is the "2.3.1" release commit? Seems like an equivalent commit exists in the 2.2.x branch.

[VRehnberg]

@bertmaher @jlebar Any updates on this?

[GaetanLepage]

Looks like 3.0.0 is out, but no commit has been tagged on GitHub.

[shimizust]

@jlebar @bertmaher Is there any update on this? Without the tags, it's hard to track down issues caused using different recent versions of triton. Could there be tags added to 2.2.0, 2.3.0, 2.3.1 and 3.0.0?

[GaetanLepage]

Hello, would it be possible to tag the 3.1.0 release ? This would make our life easier as nixpkgs maintainers.

For now, we will hand-pick this commit but this workflow is not optimal.

Thank you once again for considering our request.

[surak]

+1 for proper tags and releases. And a wheel for aarch64 as well, the one on pypi is x86_64 only and the whole thing is confusing