Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to track gitoxide releases #1311

Open
kpcyrd opened this issue Mar 8, 2024 · 1 comment
Open

How to track gitoxide releases #1311

kpcyrd opened this issue Mar 8, 2024 · 1 comment
Labels
enhancement New feature or request feedback requested

Comments

@kpcyrd
Copy link

kpcyrd commented Mar 8, 2024

Summary 馃挕

Hello!

I maintain the Arch Linux package of gitoxide and I'm having trouble keeping track of "what's the latest version of gitoxide (the program)". :)

The release notifications are unfortunately way too noisy for me to subscribe to and I noticed there's no clear pattern of tags. There are tags like v0.30.0 and v0.34.0, no version tags for everything in between (correction: there are tags, just no github releases) but uploads to gitoxide on crates.io.

I've settled on using this nvchecker config:

[gitoxide]
source = "cratesio"
github = "gitoxide"

But a user has tagged the gitoxide 0.33.0 as out-of-date, pointing to the v0.34.0 release tag which is missing on crates.io however. I also noticed there's a gix crate (which is the actual program that Arch Linux ships, along with the ein binary) that's already on version 0.58.0.

Guidance much appreciated! :)

Motivation 馃敠

Provide the latest version of gitoxide to Arch Linux users.

@kpcyrd kpcyrd added the enhancement New feature or request label Mar 8, 2024
@Byron
Copy link
Owner

Byron commented Mar 8, 2024

Thanks for sharing your experience, it's much valued and will maybe help in making improvements.

In general, the v\d+\.\d+\.\d+ pattern is the one to look for when there is interest in packaging the top-level binaries, as this tag pattern is for them only, the top-level crate. All other tags and releases are prefixed with gix-* and usually happen before a new top-level release is created. There isn't anything I think I can do about that, unfortunately, but maybe there is a GitHub feature I could use but am not aware of to improve the situation.

The current release is special. v0.33 uses gix v0.57, but an intermediate gix crate release was created for other reason as version 0.58 that isn't used by any top-level crate release. v0.34 was recently released and has binaries on GitHub, but due to human error (mine) the accompanying gix 0.59 release had to be yanked, along with a couple of other crates which ended up breaking gix v0.58 and thus the world.

With the next release, v0.35, I expect a new gix v0.60 release and everything should be back to normal.

I hope that at least explains the situation even though I can't over any improvements at this time for lack of options. Maybe it's clearer though on how to track top-level releases though?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request feedback requested
Projects
None yet
Development

No branches or pull requests

2 participants