From 0d93289bee4406bcdf00cf078cadcad367eaff38 Mon Sep 17 00:00:00 2001 From: Techatrix <19954306+Techatrix@users.noreply.github.com> Date: Mon, 27 May 2024 00:34:18 +0200 Subject: [PATCH] update README.md --- README.md | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 08ddbd2..2b17fea 100644 --- a/README.md +++ b/README.md @@ -13,7 +13,7 @@ Will respond with metadata about a ZLS build that is compatible with the given Z The response body is similar to Zig's [index.json](https://ziglang.org/download/index.json).
- Show Example + Example 1 ```bash curl "https://releases.zigtools.org/v1/select-zls-version?zig_version=0.13.0-dev.7%2B73c6c13a" # 0.13.0-dev.7+73c6c13a @@ -68,6 +68,21 @@ The response body is similar to Zig's [index.json](https://ziglang.org/download/
+
+ Example 2 + + ```bash + curl "https://releases.zigtools.org/v1/select-zls-version?zig_version=0.30.0" + ``` + + ```json + { + "error": "ZLS 0.30.* does not exist!" + } + ``` + +
+ ## /v1/select-zls-version The response body imitates Zig's [index.json](https://ziglang.org/download/index.json) except that there is no field for `master`. Development builds of ZLS should be queried by supplying the Zig version that is being used. @@ -224,7 +239,9 @@ The body is a `multipart/form-data` with the following key value pairs: All other fields are interpreted as release artifacts. The key must have the following format: -`zls-${OS}-${ARCH}-${ZLS_VERSION}.(tar.xz|zip)` (Example: `zls-linux-x86_64-0.1.0.tar.xz`) +`zls-${OS}-${ARCH}-${ZLS_VERSION}.(tar.xz|tar.gz|zip)` (Example: `zls-linux-x86_64-0.1.0.tar.xz`) + +Artifacts that target windows must be `.zip` files. All other non windows targets must include `.tar.xz` **and** `.tar.gz`. Release artifacts can also be signed with [minisign](https://jedisct1.github.io/minisign/) by publishing an additional `.minisign` file for every artifact. (Example: `zls-linux-x86_64-0.1.0.tar.xz.minisign`)