Removal of version tags makes this difficult to package

[lae]

Hi. I noticed that the v0.3.0 tag/release was removed recently, and the only tag that seems to have replaced previous version tags is latest. While I could package this, it isn't necessarily ideal when checking for updates (as there's no trivial indicator of a standard version release).

The removal of that earlier tag also has broken an existing Linux OS package that really should not have broke, hence why I'm opening this issue.

Any chance you could reinstate that version's tag, or maybe just tag and release v0.3.1 at this point?

Edit: Alternatively, if your goal is just to have no releases (always on "0.3.0") and always build on HEAD, a statement confirming such would be fine and I can hack around it to provide some sort of versioning (in the aforementioned package) based on revision count. The one problem with that is that I can't use checksum verification for the github deploy builds.

[Kethsar]

The reason for tag/version removal is because golang defaults to the most recent versioned release when using go install or go get, which ended up being annoying to deal with. The versions were originally a thing when this project was the lone Python script meant to indicate a good set of features and bug fixes had been added.

For golang, I wanted a similar case of anyone installing it that isn't grabbing the pre-built binary to get the latest code without having to force it with @master. Versioning in golang feels best left for library packages that need to provide certain guarantees. Though I will admit I am annoyed that for some reason, for me at least, it still insists on grabbing the non-existent 0.3.0 when testing on a fresh install on a server, even though someone else I know showed it properly grabs the master branch. I am unsure if I should blame some sort of caching on Github's side for this or what though, as the tag clearly does not exist anymore.

As for checksum verification, I could look into adding checksums to the artifacts for pre-releases created on push. Personally I don't know why you'd want to create a package for something as dumb as this project though, but you do you.

[lae]

adding checksums to the artifacts

This would be useful, actually.

why you'd want to create a package for something as dumb as this project

This project is really useful; don't be too hard on yourself. Plus, I think there's a decent overlap between Arch users and data hoarders, and it's really trivial on my part to create and maintain a package, especially for a prebuilt binary.

Others are definitely installing this via package, too, since the package breaking was reported the day after. I just happened to be offline during this period and thus didn't notice until today.

[Kethsar]

Would you prefer a checksum of the .zip file itself, or a checksum of the binary added to the zip? Or maybe something else.

[lae]

A checksum of the zip file itself, as that's what gets downloaded over the wire and needs to be verified (before attempting to extract).

[Kethsar]

Added in commit 1add222670eb5cf8157e4654492b91175e988479 Seeing now that the workflow action I use deletes the previous pre-release it made too. I might have to see if I can make it keep the last 10 or something just in case.

[lae]

Seeing now that the workflow action I use deletes the previous pre-release it made too.

You definitely can't duplicate tags so it's just overwriting latest (and its associated github release) to point to the newest commit as far as I can tell.

Anyway, you can close this if you want since I got the clarification I needed.

[Kethsar]

Okay, and yeah I checked the action code and figured that out. May or may not do something dumb to get around it.