Release for bugfix in #37

[EliahKagan]

This bumps the patch version, for doing an update for a 0.1.1 release on PyPI that includes the change from the fix in #37. I think it is a good idea to do this, due to the importance of the fix as noted in #37, and more generally because it can be more manageable to do more frequent smaller releases rather than accumulating many changes into less frequent bigger releases.

Since we are not yet at 1.0.0, SemVer doesn't strictly dictate if this should be 0.1.1 or 0.2.0. #37 is arguably a small but breaking change, considering how the tests needed to be changed. But it seems conceptually to be a bugfix.

This can be changed to 0.2.0 if desired. Also, whatever version is used, the bump could instead be done by some means other than this PR. The purpose of this PR is to propose that another release be done on PyPI, but if it turns out to be easier to close this PR and bump the version number in some other way, that's just as good.

I checked available versions of direct and indirect dependencies, which all appear current, so this PR modifies the version metadata only.

Note: The first CI run for this PR failed on one of the test jobs. When re-run, all jobs succeeded. I believe the failure is due to the way the test uses random numbers, as described in #45 with a proposed fix in #46. I don't think it needs to hold back the release (#46 only modifies test code, which isn't included in our PyPI package).

[EliahKagan]

@zbloss Do you want to make the v0.1.1 release? All I did here was advance the version number in pyproject.toml. GitHub will allow me to make the release, but I'm reluctant to take that action without either @bazingagin's or your go-ahead, in case there are considerations that I am unaware of. However, I'd be pleased to make the release if either of you requests that I do so.

I think the v0.1.1 release could be made from the tip of main, as it stands currently, since no new features have been added to the code in the npc_gzip subdirectory. There's nothing special about the point where this PR was merged. (#40 was since merged, but because it is minor and does not change behavior, I don't think it's a problem for that to be included.)

[bazingagin]

@EliahKagan I think we can make a v0.1.1 release, please go ahead! @zbloss please chime in if you have any other concerns!

[EliahKagan]

@bazingagin @zbloss I drafted the release here on GitHub, but unfortunately it looks like I have misunderstood what is needed for trusted publishing to work. Publishing did not succeed. I don't have prior experience using trusted publishing and I don't know if the problem is due to an account other than @zbloss triggering the release, or for some other reason. An "invalid-publisher: valid token, but no corresponding publisher" error occurred; full error output is here.

[EliahKagan]

@zbloss Are you able to manually publish or otherwise fix the failed release? As I noted about a week ago, publishing failed, and https://pypi.org/project/npc-gzip/ still has only 0.1.0. I think it may be a confusing situation for users to have https://github.com/bazingagin/npc_gzip/releases/tag/v0.1.1 here on GitHub without a corresponding release in PyPI.

I hope I'm not overstepping by pinging you again. If this isn't something we can fix in the short term, then I can mitigate the confusion by opening an issue for it, so that users who come here can find out what is going on. However, based on your :tada: reaction to the release announcement, I'm wondering if you may just have missed my previous comment and be unaware of the problem, and if the problem might actually be easily solved.

[zbloss]

Yep my bad all, I've been very under the weather recently. Looking at this now.

[zbloss]

@EliahKagan I invited you to join the project on PyPI. Once you accept I can re-run this github action.

@bazingagin I tried to add you as well but it appears you don't have a pypi account. Once you sign up for one I will invite you too.

[EliahKagan]

@zbloss Thanks. I've accepted on PyPI. After doing so, I attempted to re-run the workflow myself, which did not succeed, but I think that may not be a problem, since you were saying I should join the project so you can re-run the workflow. Please let me know if there's any other action I should take.

I hope you are feeling better soon! (And I fully understand if you are not able to put much time into troubleshooting this now.)

[EliahKagan]

I think I may know the cause of the problem. In #39, I shortened the workflow filenames, which included changing publish-package.yml to publish.yml. In hindsight, before opening that PR, I should have researched if the specific workflow filename is relied on for trusted publishing! Now that I've joined the project on PyPI, I can see that the old name, publish-package.yml, is shown for the publisher.

I will attempt to add a publisher with the new workflow filename in the project settings on PyPI, and report back.

[EliahKagan]

@zbloss @bazingagin I'm pleased to report that adding a publisher with the new workflow filename and rerunning the failed published job has succeeded. https://pypi.org/project/npc-gzip/ now has version 0.1.1. :tada:

[bazingagin]

@EliahKagan Thank you so much! @zbloss I've set up an account on pypi - same as my github username, thanks!

[EliahKagan]

@bazingagin No problem! Really @zbloss is the one to thank--once he added me to the PyPI project, I was able to see how I had myself inadvertently caused the problem in #39.

I've tried adding you, and PyPI reports that you have not verified your primary email address for your PyPI account. You should be able to do this in your account settings on PyPI; once you have, it should be possible for you to be added to the project.