Use semver tags

[julienrbrt]

Importing blocky in a go module is annoying as the tagging doesn't follow semver. For instance, for importing v0.24, I need to use the following pseudo version: v0.9.2-0.20240524080222-3ab04562fe1e.

Maybe blocky isn't meant to be used as a library, but the following semver would as well simplify its installation (on gokrazy for instance)

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[ThinkChaos]

So IIUC the idea is to add a patch bit and make the version v0.24.0?

[julienrbrt]

So IIUC the idea is to add a patch bit and make the version v0.24.0?

Yes correct!

[ThinkChaos]

Seems like a good idea to me, and coincidentally we got another related issue today (after I replied!).

@0xERR0R @kwitsch what do you think? I've got nothing against this and it seems easy to do :)

[0xERR0R]

Yes, it is a good idea to use semver in generaly. But we have to check consequences more carefully, for example arch AUR scripts just download latest binary by building the download url for github and we will brake it if we just change the versioning from x.y to x.y.z

[kwitsch]

I'm always in favor of semver.

If I remember correctly it's not the first time it was discussed. 🤔😅

But I'm pretty much unaware which consequences this would have.
Docker container would be basically unaffected and that's the only installation form I ever used.🫣

[0xERR0R]

The other question is, if we follow semver and still release every X months, we will never change the patch version, so it will be "hardcoded" to 0. Or maybe we need to change the release process and do a release more often?

[ThinkChaos]

Context for those I just brought into the conversation: we want to make sure changing the tag format to use semver won't break anything.

I took a quick look at the packages I could find:

Tagging @erkexzcx and @nicolarevelant AUR package maintainers. AFAICT from the PKGBUILDs the version is hardcoded (as are file hashes) so no risk of breaking if we leave existing tags as is. See PKGBUILDs for blocky and blocky-bin.

For the FreeBSD port (I've never looked at a port before so could be wrong) but based on the distinfo and Makefile, it looks ok too. @nunotexbsd seems to be the GH account of that maintainer.

And for Alpine the APKBUILD is very similar to the AUR though I couldn't quickly figure out the maintainer's GitHub account if they have one. There's an email if we really need to a contact at some point but the $pkgname-$pkgver.tar.gz::https://github.com/0xERR0R/blocky/archive/v$pkgver.tar.gz seem clear enough :)

nixpkgs/NixOS I don't need to check, I know it works with hardcoded versions and hashes.

Also if there's anyone out there using something that guesses the latest version, it's reassuring that v0.25.0 (if we tag that next) would be greater than both than the newest valid semver tag (v0.3.5) and the version Go invents (v0.9.1/v0.9.2).

Generally I agree it's a good idea to think about it more than just pull the trigger, but wanted to get your opinions even before that :) The one thing I see we might want to update is the container building so that any vX.Y.Z also updates the vX.Y tag, and maybe vX, as is commonly done, but that's just a nice to have IMO.

---

Re the 0 being hardcoded: I remember at least when we replaced the list parsers we did a couple bug fix releases quickly after, so those could've been patches.
But yeah it's probably going to be essentially hardcoded at 0 most of the time, though I don't think that's really an issue.

[kwitsch]

Regarding our release cycle the patch level would be 0 most of the time.
An exception was already mentioned by @ThinkChaos .

[nicolarevelant]

Hi, I maintain blocky AUR package.

When you publish a new release, i will update the package with the new version. If the new version is lower (0.24 --> 0.9) I will increment epoch number