About version number

[jinzhongjia]

Currently zig's package for webui is fully available

Maybe we can release a version.
But I don’t know if it needs to be synchronized with the version number on the webui side, aha?

@hassandraga

And I plan to continue to improve the buildz.zig of the webui library later.

[hassandraga]

You can start from 1.0.0 if you want, but all other webui wrapper versions are synced with the webui core version to distinguish which core version is being used, so it will be good if also Zig follows the same schema.

The actual core version is 2.4.2, so it's okay to start with 2.4.2.0, or 2.4.2. Then, increase the patch version .2 for every new Zig release while keeping 2.4 (major.minor) sync with the core version.

[jinzhongjia]

I get it, but since the current zig-webui depends on webui main branch, I plan to wait for the next release of webui and release it together.

[ttytm]

@jinzhongjia there were discussions about it here webui-dev/webui#137.

Afaik the latest state is using a <x.x.x>-<x.x> convention for the wrappers. Where the first <x.x.x> is the semver of the WebUI C version that the wrapper is using, and the second two are used for the wrappers individual versioning.

There is also a reference in the link above to another issue regarding this.

[ttytm]

What I observe so far when using the convention described above:

go get with @latest (e.g.: go get github.com/webui-dev/go-webui/v2@latest) won't get a version like v2.4.2-1.0, only v2.4.2. It is required is to set it explicitly: go get github.com/webui-dev/go-webui/[email protected] else it is seen as a pre-release.

The behavior is described here: https://go.dev/ref/mod#version-queries

Release versions are preferred over pre-release versions. For example, if versions v1.2.2 and v1.2.3-pre are available, the latest query will select v1.2.2, even though v1.2.3-pre is higher. The <v1.2.4 query would also select v1.2.2, even though v1.2.3-pre is closer to v1.2.4. If no release or pre-release version is available, the latest, upgrade, and patch queries will select a pseudo-version for the commit at the tip of the repository’s default branch. Other queries will report an error.

So we might can do some fine-tuning make wrapper-based adaptations regarding the versioning.

---

Edit:
I think it's still good to use that way, since go get also accepts a branch names, e.g., go get github.com/webui-dev/go-webui/v2@main.

I would just update the Go wrappers readme to include:

go get github.com/webui-dev/go-webui/[email protected]

and

go get github.com/webui-dev/go-webui/v2@main

instead of

go get github.com/webui-dev/go-webui/v2@latest

[jinzhongjia]

Yes, I think this is a better solution, but zig does not have the latest feature of go, and its packages can come from anywhere