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`)