chore: Add RELEASING.md, minor update to mod.md

doc/RELEASING.md

@@ -0,0 +1,89 @@
+# How to publish a new release
+
+## 1. Ensure you're fully in sync with the remote repo
+
+```bash
+git switch main
+git pull
+git status
+```
+
+## 2. Create the release branch
+
+```bash
+git switch -c vX.Y.Z
+```
+
+## 3. Update all the occurrences of the version in the repo
+
+```bash
+bump2version --config-file .bumpversion.cfg <increment>
+```
+
+The `increment` parameter can be:
+
+- `patch`
+- `minor`
+- `major`
+
+Use the one appropriate to the version increment you're releasing.
+
+## 4. Refresh `Cargo.lock`
+
+```bash
+cd questdb-rs-ffi
+cargo clean
+cargo build
+```
+
+## 5. Merge the release branch to master
+
+```bash
+git commit -m "Bump version: <current> → <new>"
+```
+
+Replace the `<current>` and `<new>` placeholders!
+
+Create and merge a PR with the same name: "Bump version: \<current\> → \<new\>"
+
+## 6. Tag the new version
+
+Once the PR is merged, pull main and add the version tag:
+
+```bash
+git switch main
+git pull --prune
+git tag X.Y.Z
+git push --tags
+```
+
+## 7. Create a new release on GitHub
+
+[GitHub Release Page](https://github.com/questdb/c-questdb-client/releases)
+
+On that page you'll see all the previous releases. Follow their manually-written
+style, and note that the style differs between patch, minor, and major releases.
+
+## 8. Publish the Rust crate to crates.io
+
+Ensure once more you're fully in sync with the remote repo:
+
+```bash
+git switch main
+git pull
+git status
+```
+
+Publish the crate:
+
+```bash
+cd questdb-rs
+cargo publish --dry-run --token [your API token from crates.io]
+cargo publish --token [your API token from crates.io]
+```
+
+## 9. Ensure the docs are online on docs.rs
+
+The release is immediately visible on crates.io, but there's a delay until it
+becomes available on [https://docs.rs/](docs.rs). Watch that site and ensure it
+appears there.

questdb-rs/src/ingress/mod.md

@@ -65,27 +65,6 @@ QuestDB instances), call
 The two supported transport modes, HTTP and TCP, handle errors very differently.
 In a nutshell, HTTP is much better at error handling.
 
-# Health Check
-
-The QuestDB server has a "ping" endpoint you can access to see if it's alive,
-and confirm the version of InfluxDB Line Protocol with which you are
-interacting:
-
-```shell
-curl -I http://localhost:9000/ping
-```
-
-Example of the expected response:
-
-```shell
-HTTP/1.1 204 OK
-Server: questDB/1.0
-Date: Fri, 2 Feb 2024 17:09:38 GMT
-Transfer-Encoding: chunked
-Content-Type: text/plain; charset=utf-8
-X-Influxdb-Version: v2.7.4
-```
-
 ## TCP
 
 TCP doesn't report errors at all to the sender; instead, the server quietly
@@ -110,6 +89,27 @@ message.
 After the sender has signalled an error, it remains usable. You can handle the
 error as appropriate and continue using it.
 
+# Health Check
+
+The QuestDB server has a "ping" endpoint you can access to see if it's alive,
+and confirm the version of InfluxDB Line Protocol with which you are
+interacting:
+
+```shell
+curl -I http://localhost:9000/ping
+```
+
+Example of the expected response:
+
+```shell
+HTTP/1.1 204 OK
+Server: questDB/1.0
+Date: Fri, 2 Feb 2024 17:09:38 GMT
+Transfer-Encoding: chunked
+Content-Type: text/plain; charset=utf-8
+X-Influxdb-Version: v2.7.4
+```
+
 # Configuration Parameters
 
 In the examples below, we'll use configuration strings. We also provide the