You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Zig 0.12.0 has released last week as the current stable release as of writing. For the time being, the 0.13.0 has not diverged too much from 0.12 to require any plugin changes.
When such a change eventually happens, there will be a couple choices available for how to continue the plugin development moving forward:
ZigBrains will always follow the latest development builds of Zig all the way until 1.0, and then only update the plugin when stable builds come out
Only publish latest-stable-zig builds of ZigBrains on the marketplace, and versions that support the current master branch release would only be available on github and my website. Unforunately, doing multi-version on the marketplace is not viable due to their versioning restrictions.
ZLS seems to be doing something similar to this second one, where they publish tagged releases for each tagged zig release, and then continue development on the master branch. This could be viable, however, ZigBrains itself also has its own set of bugs and features that evolve differently from Zig/ZLS that would need to be backported for feature parity.
This is made even worse by the fact that ZigBrains also needs to target multiple IntelliJ version, so just supporting the 4 latest versions of IDEs, plus 2 zig releases (stable and master) would already require 8 different concurrent branches:
Do the exact same thing as 2., but the IDEA-Zig version pairs would be voted on by the community. If an IDEA-zig version pair doesn't receive any votes, then it will be dropped from maintenance. This will gradually push ZigBrains along with the IDE and Zig release schedules, while not cutting off support blindly. This would be my preferred approach, as i don't want to rely on purely the downloads statistics from the marketplace
The text was updated successfully, but these errors were encountered:
Personally, I prefer the first option, as it involves the least amount of legacy maintenance burden, and I already always use the latest zig+zls+IDEA versions, so I have no use for the backports, but that's why I'm also asking everyone else too.
the ZLS issue has been closed, i'm closing this page too with the same result: ZigBrains versions released during the lifecycle of a specific zig version will keep working with that zig version, but newer versions of the plugin may or may not work with older zig releases.
Zig 0.12.0 has released last week as the current stable release as of writing. For the time being, the 0.13.0 has not diverged too much from 0.12 to require any plugin changes.
When such a change eventually happens, there will be a couple choices available for how to continue the plugin development moving forward:
ZLS seems to be doing something similar to this second one, where they publish tagged releases for each tagged zig release, and then continue development on the master branch. This could be viable, however, ZigBrains itself also has its own set of bugs and features that evolve differently from Zig/ZLS that would need to be backported for feature parity.
This is made even worse by the fact that ZigBrains also needs to target multiple IntelliJ version, so just supporting the 4 latest versions of IDEs, plus 2 zig releases (stable and master) would already require 8 different concurrent branches:
master_dev
master_0.12.0
233_dev
233_0.12.0
232_dev
232_0.12.0
231_dev
231_0.12.0
The text was updated successfully, but these errors were encountered: