Increase version number in auto-releases?

[jafingerhut]

If you do git tag -l on this repository as of 2026-May-28, you see these versions:

$ git tag -l
v0.10.0
v0.11.0
v0.11.1
v0.12.0
v0.9.4

If you look on the pypi.org release history page for the ptf package here: https://pypi.org/project/ptf/#history you will see these versions:

0.12.0 2026-May-02
0.10.0 2023-Jun-22
0.9.4 2023-Jun-13
0.9.3 2022-Jan-13
0.9.2 2022-Jan-13
0.9.1 2021-Sep-07

Version.txt contains version 0.11.1, which I believe was the last version to be released via the latest automatic monthly release process, which I believe creates a tag in this repo, but DOES NOT create new version published to pypi.org.

It would be good to clean this up a bit, perhaps by doing the following:

• Increase the version number in Version.txt to something numerically larger than the 0.12.0 maximum version number that is published to pypi.org, perhaps 0.13.0 ?
• Maybe document somewhere that tags 0.11.x are actually later versions of the code than tag 0.12.0, due to mistakes that we made. If we can change the names of those tags, maybe that is a good idea, too, but I'm not very knowledgeable of whether updating git tags might cause trouble for anyone.
• I don't know if it would be a good idea to try to automate publishing of new versions to pypi.org or not. Thoughts?

[jafingerhut]

Note: I am pretty sure it was me that chose version number 0.12.0 for the 2026-May-02 release to pypi.org. My bad for not updating Version.txt to a later version at that time.

[fruffy]

I am trying to understand how this happened. So basically we pushed a release with the tag 0.12.0 but we did not update the version identifiers in the source repository?

I thought pushing to pypi was already automated. If not, this definitely needs to be done.

Considering that 12.0 is on pypi but the recent releases haven been skipped it is safe to update to 12.1 and fix this mistake. The automated release bot should pick this up. We can also clean up the latest 11.0 tags before it's too late.

[jafingerhut]

I am trying to understand how this happened. So basically we pushed a release with the tag 0.12.0 but we did not update the version identifiers in the source repository?

I thought pushing to pypi was already automated. If not, this definitely needs to be done.

Considering that 12.0 is on pypi but the recent releases haven been skipped it is safe to update to 12.1 and fix this mistake. The automated release bot should pick this up. We can also clean up the latest 11.0 tags before it's too late.

I am pretty sure it happened because when I made the release to pypi on 2026-May-05 (I am pretty sure it was me), I followed the instructions in this article: https://github.com/p4lang/ptf/blob/main/README-publish-python-package.md

and that article describes a manual process that has no mention of Version.txt, because I had no knowledge of Version.txt at the time I added and followed those instructions.

If there is an automated process for publishing new versions of ptf packages to pypi.org, it would be good to update README-publish-python-package.md to describe how to trigger it.

[chreekat]

Publishing to pypi is triggered based on the creation of a tag matching the glob v*, which is implied by the instructions in https://github.com/p4lang/ptf/blob/main/README-publish-python-package.md. So far, so good.

What that document seems to be missing is that version tags v* are created automatically whenever Version.txt gets updated on main.

Even more importantly, Version.txt is treated as the single source of truth for the most recent release.

The automated monthly releases simply open a PR to change the Version.txt file, and everything flows down from that.

If someone manually changes Version.txt, that will also trigger a pypi release.

So, the README could be updated to say as much.

Since manually changing Version.txt involves a commit (and not just the creation of a tag) you may want to add something about changelogs or whatever. I don't actually know the policies around manual version changes in this -- or other -- repos. :)

[jafingerhut]

Publishing to pypi is triggered based on the creation of a tag matching the glob v*, which is implied by the instructions in https://github.com/p4lang/ptf/blob/main/README-publish-python-package.md. So far, so good.

Thanks for the info. I will consider creating a PR to update that README to be more explicit about that. Before I update the instructions, I'd like to personally go through the modified steps there with the next release we make to pypi.org, to verify that the updated instructions are correct.

[jafingerhut]

OK, another follow-up question.

I am fairly certain that I manually created the tag v0.12.0 (when it would have been better if I did not do so -- but that is water under the bridge now). Shortly after I pushed that tag, version 0.12.0 of the ptf package on pypi.org was created and published, via one of the Github CI tasks that does this. 0.12.0 is the latest version on pypi.org as of when I wrote this comment: https://pypi.org/project/ptf/

At some point something caused a tag v0.12.1 to be created in this repository. I am fairly certain that I did not create it. I do not know what caused that to happen. Whatever caused tag v0.12.1 to be created, it did not cause version 0.12.1 of the ptf package to be published to pypi.org. Question: Why not?

[jafingerhut]

OK, another follow-up question.

I am fairly certain that I manually created the tag v0.12.0 (when it would have been better if I did not do so -- but that is water under the bridge now). Shortly after I pushed that tag, version 0.12.0 of the ptf package on pypi.org was created and published, via one of the Github CI tasks that does this. 0.12.0 is the latest version on pypi.org as of when I wrote this comment: https://pypi.org/project/ptf/

At some point something caused a tag v0.12.1 to be created in this repository. I am fairly certain that I did not create it. I do not know what caused that to happen. Whatever caused tag v0.12.1 to be created, it did not cause version 0.12.1 of the ptf package to be published to pypi.org. Question: Why not?

Thanks again for explaining.

But if all you say is correct, why isn't there a version 0.12.1 of the ptf package published on pypi.org right now?

[fruffy]

As far as I understand we do not publish automatically to pypi right now. I do not remember whether we have the credentials here. They might not work.

[fruffy]

https://github.com/p4lang/ptf/actions/workflows/pypi.yml it looks we are not triggering this.

[chreekat]

So it looks like we can publish, but it doesn't usually happen the way we expect. The intent seems to be "publish to pypi when a tag is pushed." But that didn't happen for v0.12.1. Looks like a bug in the workflow?

[jafingerhut]

So it looks like we can publish, but it doesn't usually happen the way we expect. The intent seems to be "publish to pypi when a tag is pushed." But that didn't happen for v0.12.1. Looks like a bug in the workflow?

The workflow for publishing a new release to pypi.org definitely worked in early 2026-May when I manually pushed a tag v0.12.0 to the ptf repo. I don't know the difference between what I did then vs. the more recent pushing of tag v0.12.1 via some automated means.

[chreekat]

Looks like a bug in the workflow?

Argh, GitHub's heavy-handed guardrail is the issue here.

https://docs.github.com/en/actions/concepts/security/github_token#when-github_token-triggers-workflow-runs

In the automated workflow, the tag is created with permissions provided by the GITHUB_TOKEN. Therefore, the followup workflow that would fire when a tag is pushed is just silently blocked and dropped.

I will fix this.

[chreekat]

The fix for this is proposed at #263