-
-
Notifications
You must be signed in to change notification settings - Fork 268
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rethink how ZLS maintains backwards compatibility #1020
Comments
This is just me writing my thoughts down, anything im missing or you disagree with let me know and I will update it. StrictPros:
Cons:
RelaxedPros:
Cons:
Split BranchesPros:
Cons:
|
To be honest, I really like the strict approach, at least for the moment. Because Zig is pre-1.0, it's inherently unstable and fast-moving. I think that we could take this approach until 1.0 is reached and then switch to the relaxed approach. The split branches approach seems untenable. |
I agree with you, it was all well and good doing a little bit of comptime magic in |
In order to go with the strict approach the vscode extension will need some way of downloading and choosing between different versions of ZLS. |
I see this warning:
Related?
I guess developers like to use tools such as |
that issue is being tracked here. |
Now that ziglang/vscode-zig#138 is merged the main motivation of #1411 is gone (at least for vscode users). As we are providing specific versions of zls for specific versions of zig now, is there any reason for us to keep zig version specific build runners? |
Even though the main motivation is gone, I still believe there is use in keeping this feature. ZLS master contains numerous bug fixes and improvements over older tagged releases. So until there is something like a breaking syntax change that would prevent this use case, I would suggest to keep #1411. |
This has partially be brought up in #1000 and #1019
With the numerous breaking changes to the Zig language and its build system, it became harder to maintain compatibility with older Zig versions. This issue is only going to get worse as more versions are released and Zig's development accelerates.
I think its time to discuss ZLS's plan on how its going maintain compatibility with Zig.
Its harder to make a decision without knowing how many people are going to be affected by certain changes.
How many people use a pre 0.10.x release of Zig with ZLS master?
How many people use ZLS master compared a tagged release?
What version(s) do Zig projects tend to require?
How quickly do projects transition to new versions of Zig?
Despite that, here are some possibilities i could think of:
Strict
ZLS master only maintains compatibility with Zig master.
A tagged release of ZLS is only compatible with the same tagged release of Zig.
Relaxed
ZLS master can only be compiled with Zig master and is compatible with Zig master and the the latest tagged release of Zig.
A tagged release of ZLS must be compiled with and is only compatible with the same tagged release of Zig.
Split branches
We take the Strict Proposal but also maintain separate branch of ZLS that backports changes while maintaining compatibility with the latest tagged release of Zig.
The text was updated successfully, but these errors were encountered: