zig-network
zig-network copied to clipboard
Provide a branch based on the latest Zig release
Hi @MasterQ32 !
When Zig 0.7 will be released, I plan to use zig-network in combination with h11 to try to build an HTTP client library. Zig is young and move fast so I understand the value of compiling zig-network with Zig master branch.
As we get closer to Zig 1.0, would it be possible to provide a branch for zig-network that compile with the latest release of Zig ?
Maybe something like:
- The master branch compile with the latest Zig release (0.7, 0.8, etc...), in order to provide stability to the users.
- A develop branch compile with Zig master branch, in order to provide the latest language benefits but also feedbacks for the Zig compiler.
What do you think ?
Have a nice day 🌴
I think this scheme makes sense, I'm planning to do this for zls as well.
I think it's better to have tags that come along with zig releases. These would be old snapshots and not be backported when new features come, as it's too much work for a "deprecated" version, but just have a tag zig-0.7.0 which you can check out should be enough
Thanks for you replies !
Does using tags makes it easy to add a bugfix ?
For example, when Zig 0.7 is released you will make a zig-0.7.0 tag.
Then, Zig master branch add a breaking change or a new API that you use in zig-network master branch.
Someone find a small bug in the zig-0.7.0 tag, which is fixed in the master branch.
In this situation, can I provide a bug fix for zig-0.7.0 or should I wait for the next zig-0.8.0 ?
EDIT:
I have the situation right now, where I build my projects against Zig 0.6.0 but zig-network uses std.io.Writer so I figured out this morning I was blocked :P
No, it would not be possible. And imho i don't see much sense in providing backports of bugfixes to earlier versions, it's just twice the work (i consider it maintaining two, three, four, … libraries, depending on how much zig versions will come until 1.0)
Fine then !
I am looking forward to see this zig-0.7.0 tag :)