Consider upgrading test runner version

[keiravillekode]

We could support version 2 of the test runner interface. The differences between version 2 and version 3 are only relevant for concept exercises, and we currently don't have any.

We would need to parse the test output.

Should we use bash awk jq sed, like the approach used by the bash awk jq tracks?

Or should we use a zig program, like the approach used by the cpp free-pascal nim tracks? If so, should we wait until the track has moved to Zig 0.16+

[keiravillekode]

cc @ee7

[kotp]

Should this be discussed on the forums at https://forum.exercism.org/c/programming/zig/199 similar to where other maintenance talks happen?

This helps us keep the issues list more of a confirmed todo list than a place where things make noise and have to be closed later.

[keiravillekode]

Example solution using the jq approach, produced with Claude.

exercism/zig-test-runner@main...keiravillekode:zig-test-runner:version-two-jq-sed

The forum conversation would likely become about "When are we moving to Zig 0.16+?"

[kotp]

TL;DR: In any case, judge this issue, as it currently is, against the mirror of this blog post in 2023: https://exercism.org/blog/contribution-guidelines-nov-2023 It goes over guidance for contributing, and where the discussion should be had, and a few other things. For more details, see the rest responded to inline...

On 26/04/17 10:02PM, keiravillekode wrote: keiravillekode left a comment (exercism/zig#546) Example solution using the `jq` approach, produced with Claude. [https://github.com/exercism/zig-test-runner/compare/main...keiravillekode:zig-test-runner:version-two-jq-sed](https://github.com/exercism/zig-test-runner/compare/main...keiravillekode:zig-test-runner:version-two-jq-sed)

I appreciate the patch, as reviewed via https://github.com/exercism/zig-test-runner/compare/main...keiravillekode:zig-test-runner:version-two-jq-sed.patch

The forum conversation would likely become about "When are we moving to Zig 0.16+?"

Perhaps, but that is a presumption, and as worded, you are not even 100% sure of that. The maintainers are there, and other track maintainers are there that can give benefits to going one direction or another, even more so that you have mentioned other tracks and how they have done things. You asked two questions with an addendum... but created an issue that has no direction since there was no discussion. By it's very nature, part of this issue will be declined, a part may be accepted. Instead, having the discussion can cause the creation of the issue when it is decided, and that issue is likely to be focused, and accepted. Indeed, the link you have presented is work being done that has not yet been discussed and so may be rejected, work that did not yet need to be done. But I think it is more efficient to have the discussion before the issue is created, making the issue become more focused, and pre-accepted, and having the work done already discussed and accepted. I think also, perhaps, the README.md file for this repository should be populated to help guide contributors to know where to go and when to create an issue, some tracks are strongly on the forum (discuss before creating an issue), while some tracks are more open to issues being created before discussion.

[keiravillekode]

Example solution using the zig 0.15.2 approach, produced with Claude.

exercism/zig-test-runner@main...keiravillekode:zig-test-runner:version-two-zig

Example migration from zig 0.15.2 approach to using zig 0.16.0

keiravillekode/zig-test-runner@version-two-zig...keiravillekode:zig-test-runner:version-two-zig-0.16.0

main...keiravillekode:zig:zig-0.16.0 (doc links currently broken)

[keiravillekode]

Forum thread