Proposal: Use git tags to make ziglings compatible w/ specific zig versions

[ratfactor]

Proposal: Use git tags to make ziglings compatible w/ specific zig versions

[ratfactor]

@guillaume-roche Fantastic!

@postspectacular Thanks again for the suggestion. I think this is going to be very helpful.

[ratfactor]

Thanks @postspectacular! Sounds like branches would be ideal so long as they're correctly described in the README.

@guillaume-roche , that's a really good point about the official releases like 0.8.1, especially since those are what's linked right on the ziglang.org homepage.

Since it sounds like you already have a start on it, I've created a v0.8.1 branch and put a note on its README:

https://github.com/ratfactor/ziglings/blob/v0.8.1/README.md

I would be delighted if you could contribute the changes to make it work with that version. ❤️

(As an aside, you don't have to build the master branch from source (I'm lazy too, ha ha) - there are nightly builds here: https://ziglang.org/download/)

[postspectacular]

@ratfactor no, THANK YOU, for this amazing resource!

[ratfactor]

@postspectacular Thanks a lot for this idea! I am very sympathetic to those who have their own compiled builds of Zig, especially since I'd like to be in that club soon myself (32bit RPI, exactly like your example).

Tagging version bumps wouldn't be hard (the hard part would be remembering to do it).

My only concern is that old tagged commits could never get bug fixes, improvements, and new exercises.

What I've been wondering about (since I saw your proposal come in 3 days ago) is if it would be worth doing this with branches instead. In theory, it's no harder to make a branch than a tag, but would still let me make updates.

It seems to me that worst case, I decide it's too hard to maintain 5 old versions and just stop updating the old version branches. That'd be the same as having tagged commits, right?

I'm trying to think of a downside. Can you think of anything?

[postspectacular]

Hey @ratfactor - sorry for the delay. I'm glad to hear you're not opposed to it & personally I think it's still better to have some examples working at all (buggy or not) rather than missing out entirely. I also do agree that branches are a somewhat better solution, though I too think you can help your future self by explicitly pointing out in the readme that these branches are merely constituting passively maintained snapshots compatible with the stated versions of the language and that only the tip of this repo is being actively maintained. Something along these lines will just help to set expectations. If other people want to contribute fixes for some of the branches, so be it - at least you provide the necessary mechanism/setup...

[guillaume-roche]

Hi, thanks for this repo!

Interesting discussion. If I may, I think also that branches would be better. I just installed latest 0.8.1 zig release, and then I found out about this repo to learn it. As I'm lazy, I preferred to find local fixes to make it work with 0.8.1, rather than building from sources.

For now, I really didn't have to change much, we will see as I make progress in the ziglings. I guess we could say this is a "meta-zigling" to handle.

Anyway, I would be happy to contribute to an eventual 0.8.1 branch.

[guillaume-roche]

Thanks @ratfactor , I just opened a PR, with a slight typo in my branch name, I hope it's good enough.

(As an aside, you don't have to build the master branch from source (I'm lazy too, ha ha) - there are nightly builds here: https://ziglang.org/download/)

Thanks for the tip. I didn't really check the download page, as I installed Zig with my package manager. ;)