search

marler8997 / zig-unofficial-releases

A list of unofficial zig releases
https://marler8997.github.io/zig-unofficial-releases/
44 stars 2 forks source link

Machine readable version #9

Open elerch opened 1 year ago

elerch commented 1 year ago

Thanks for putting this together - it is super useful! It would be helpful if there was a machine readable version of this, similar to https://ziglang.org/download/index.json

That would allow various CI/CD systems to track to unofficial releases rather than simply "master". Is that something you'd be willing to entertain?

marler8997 commented 1 year ago

Yeah I've had the same thought. I haven't identified a specific use case for it yet though. I'm not sure I understand the specifics of a CI system tracking these releases? They wouldn't be auto-updating to the latest release whenever one is made would they?

elerch commented 1 year ago

There are two different "setup zig" actions in the GitHub marketplace to my knowledge:

https://github.com/marketplace/actions/setup-zig and https://github.com/marketplace/actions/setup-zig-environment

Both of them allow pinning to a version or just following master (effectively auto updating). I think an auto-update is useful when zig is getting closer to a release as it is now. For instance, between now and maybe mid May, auto-update libraries to these unofficial releases. If the end of May seems to hold, libraries can then switch to ziglang.org/download for the last couple weeks, then have a library release that coincides with the release date of 0.11.

I know https://github.com/truemedian/zfetch was trying to keep up with master in this manner. It was ultimately archived due to the churn of keeping up with daily master changes...of course we have a client now in 0.11, but that's a different part of this story. ;-) A two week auto-update would still have been frustating for @truemedian I'm sure, but it would have given them a 2 week window where things aren't changing under them, and those using zfetch would have something semi-stable as well.

If you're an application author dependent on several libraries doing the same thing, then you're not struggling as much because you effectively have known stop points amongst these libraries, run through CI with a known good/bad status against each compiler version.

Another advantage comes to mind in terms of cross-platform. Easy enough to update one URL, but if I could say "I want this date's unofficial release" and the CI can look up and grab whatever version is appropriate for the OS and arch, it's a lot easier than doing this by hand. Right now this can be done but it is only based on the zig numbering scheme.

motiejus commented 1 year ago

I have another use case: hermetic_cc_toolchain releases. Currently it is hand-picked from this repository (via the process outlined in https://github.com/uber/hermetic_cc_toolchain/wiki/Release-Process#1-upgrade-the-zig-sdk) , but the more we can add to code, the better.

tristanisham commented 1 year ago

Hey @marler8997, I build and maintain zvm. Currently, when user's want to update their master install, it only downloads the newest release. With a machine readable version, I could give users a more nuanced selected, bolstering their development capabilities and my tool.

kassane commented 1 year ago

There are two different "setup zig" actions in the GitHub marketplace to my knowledge:

https://github.com/marketplace/actions/setup-zig and https://github.com/marketplace/actions/setup-zig-environment

New alternative with zig-cache https://github.com/Hanaasagi/zig-action-cache

motiejus commented 1 year ago

Both @marler8997 and myself don't see a direct benefit ourselves so we are unlikely to build it, but I believe we would be happy to support it if someone interested would be inclined to contribute.

First proposal: have a versions.ini alongside, which "public API" could be hosted at https://raw.githubusercontent.com/marler8997/zig-unofficial-releases/master/versions.ini

Turns out half of the work is done -- makelinks.zig is a thing that we run every two weeks, so feels like a good place for such a functionality.