Documentation tweaks - wording, typos, changelog (#403)

* fix typo in queries
* tweak tip on debug build tag
* remove dev badges
* prepare changelog for release

CHANGELOG.md

@@ -1,4 +1,15 @@
-## [[unpublished]](https://github.com/mlange-42/arche/compare/v0.10.1...main)
+## [[v0.11.0]](https://github.com/mlange-42/arche/compare/v0.10.1...v0.11.0)
+
+### Highlights
+
+Arche now has a dedicated [documentation site](https://mlange-42.github.io/arche/)
+with a structured user guide and background information.
+We hope that this will lower the barrier to entrance significantly.
+
+Further, Arche got a few new features:
+* `Query.EntityAt` was added for random access to query entities.
+* Generic filters now support `Exclusive`, like ID-based filters.
+* Build tag `debug` improves error messages in a few places where we rely on standard library panics for performance.
 
 ### Breaking changes
 
@@ -14,7 +25,7 @@
 ### Documentation
 
 * Adds a dedicated Arche [User Guide](https://mlange-42.github.io/arche/) web site (#380, #382, #383, #384, #385)
-* Adds [BENCHMARKS.md](https://github.com/mlange-42/arche/blob/main/BENCHMARKS.md) for a tabular overview of the runtime cost of typical *Arche* ECS operations (#367, #372)
+* Adds ~~[BENCHMARKS.md](https://github.com/mlange-42/arche/blob/main/BENCHMARKS.md)~~ [benchmarks](https://mlange-42.github.io/arche/background/benchmarks/) for a tabular overview of the runtime cost of typical *Arche* ECS operations (#367, #372)
 * Link benchmarking code in `README.md` and benchmarking tables (#375)
 * Documents build tags `tiny` and `debug` in package docs of `ecs` (#377)
 * Adds examples to demonstrate the use of non-ECS data structures together with ECS (#379)

docs/content/guide/filters/index.md

@@ -51,7 +51,7 @@ Here, we filter for all entities that have a `Position`, but no `Heading`. Other
 
 ### Exclusive
 
-With {{< api ecs Mask.Exclusive >}} and {{< api generic Filter2.Exclusive >}} {{% dev "v0.11" %}},
+With {{< api ecs Mask.Exclusive >}} and {{< api generic Filter2.Exclusive >}},
 we can exclude all components that are not in the filter:
 
 {{< tabs >}}

docs/content/guide/queries/index.md

@@ -36,13 +36,13 @@ current query iterator position.
 
 Comparing the two versions of the code above, one can clearly observe the advantages of the generic API
 over the ID-based API (see chapter on [APIs](./apis)).
-Firstly, the generic code is shorter and more readible.
+Firstly, the generic code is shorter and more readable.
 But even more importantly, it much safer.
 A little mistake in line 9 or 10 of the ID-based version could result in silently casting a component
 to the wrong type, which would lead to bugs that are hard to track down.
 
 {{% notice style="blue" icon="bug" title="Tip" %}}
-In case you get error messages like "index out of range [-1]" or "invalid memory address or nil pointer dereference" from queries, try running with build tag `debug`:
+If you get error messages like "index out of range [-1]" or "invalid memory address or nil pointer dereference" from queries, you are probably using them in the wrong way. Try running with build tag `debug` for more helpful error messages:
 
 ```
 go run -tags debug .
@@ -80,8 +80,6 @@ After {{< api ecs Query.Count >}}, the query could also be iterated as usual.
 
 ### Query.EntityAt
 
-{{% dev "v0.11" %}}
-
 With {{< api ecs Query.EntityAt >}}, queries also support access by index.
 This is particularly useful to select random entities from a query,
 like in this example: