create new and working release

[Byron]

Tasks

• yank everything of previous release
• create new release with bumped minor versions (cargo set-version --bump minor -p <crate> to the rescue)

[EliahKagan]

• yank everything of previous release

I am not at all sure, but I've included some information about my observations in #1970 (reply in thread) that makes me wonder if maybe not everything has to be yanked and redone.

[Byron]

I am not at all sure, but I've included some information about my observations in #1970 (reply in thread) (near the end) that makes me wonder if maybe not everything has to be yanked and redone.

Even though a more fine-grained approach might have been possible in theory, I went for the blanket manual yanking as it was supposed to definitely work. This was facilitated by still having the publish logs in the terminal.

What's more worrisome is that this happened in the first place - it shouldn't have been possible unless, of course, I somehow managed to not indicate a breaking change in the originating crate again. gix-index ended up as patch release, but referred to a breaking release of gix-object, from what I could tell. This should have minor-bumped gix-index too.

For now I have no reason to assume this system isn't working at all, but it's clear there are ways to 'work around' it.

[EliahKagan]

These releases, including for gitoxide v0.44.0, seem to have completed successfully, and you merged this PR. I noticed that the release workflow was not run for v0.44.0. Although the built v0.43.0 assets seem to run with no problems, that version is among the recently yanked packages, so people may prefer not to use it, or may not be confident that it preferable to older versions.

Furthermore, I am not aware of any special reason the release workflow should not be run, to build assets for gitoxide v0.44.0 and populate the GitHub release with it, and to post to the announcement discussion (#1693), thereby expressing that we really do want people to use this release. I believe such assets are also necessary for some automated installation methods, including cargo-binstall and various GitHub actions.

Thus, I have gone ahead and run the release workflow via the workflow_dispatch trigger on the v0.44.0 tag. This seemed to work fine. All jobs completed successfully, the expected assets are attached to the GitHub release, and the expected comment is posted in the announcement thread.

It occurs to me that there is no descriptive text about the release. However, that appears to have been intentional. (If not intentional, a description can always be added later.)

[Byron]

Thank you! Indeed I have just forgotten it (again).