docs: the benchmark tooling moved to mmdbbench; the engine tag of a JVM wheel for an A/B

README.md

@@ -128,7 +128,7 @@ Open an [issue](https://github.com/ArcadeData/arcadedb-python/issues) or a pull
 
 ## Where this code comes from
 
-It moved here from `bindings/python` in [ArcadeData/arcadedb](https://github.com/ArcadeData/arcadedb) at `ee04bd202abce0183c6263a3c4d8a61a4d526960`, with its git history. Issue numbers in older commit messages refer to that repository. [humemai/arcadedb-embedded-python](https://github.com/humemai/arcadedb-embedded-python) is the fork where the bindings kept developing (runtime fixes, JRE trim, the native build, benchmarks). Its benchmark tooling stays there. <!-- allow-old-name -->
+It moved here from `bindings/python` in [ArcadeData/arcadedb](https://github.com/ArcadeData/arcadedb) at `ee04bd202abce0183c6263a3c4d8a61a4d526960`, with its git history. Issue numbers in older commit messages refer to that repository. [humemai/arcadedb-embedded-python](https://github.com/humemai/arcadedb-embedded-python) is the fork where the bindings kept developing (runtime fixes, JRE trim, the native build, benchmarks). Its benchmark tooling moved to [humemai/mmdbbench](https://github.com/humemai/mmdbbench). <!-- allow-old-name -->
 
 ## Citation
 

docs/modules/ROOT/pages/development/ci.adoc

@@ -65,6 +65,8 @@ The two packages get their engine from different places, so between releases the
 * `test-jvm.yml` and `test-python-examples.yml` take the engine jars from the `arcadedata/arcadedb` image tag, `latest` by default. `latest` is upstream's newest snapshot and moves nightly, which is why both workflows also run every night.
 * `test-native.yml` links `DEV_ENGINE`, the newest release on Maven Central, unless the tag is a final or post version (then it links the release the tag is named after) or the `engine` input of a manual run says otherwise.
 
+A JVM wheel that must carry the same engine as a release, such as the wheel of an A/B or of a release gate, comes from a manual run of `test-jvm.yml` with the release's engine tag: `gh workflow run "Test JVM (arcadedb-jvm)" -R ArcadeData/arcadedb-python --ref <branch> -f arcadedb-tag=26.11.1` (the engine of `26.11.1` and its `.postN` releases). Without the input the jars come from `latest`, the wheel carries another engine than the release, and a comparison with the release measures the engine as well as the change. The native build needs no such input, because it links a release engine by default.
+
 A manual run of `test-native.yml` with a `devN` version may set `engine` to `A.B.C-SNAPSHOT`: `native/pom.xml` then resolves the engine jars from the Sonatype snapshot repository (snapshots on, releases off, so a release version still comes from Maven Central alone). The notices comparison of `build_wheel.py` is skipped for such a run, because `THIRD_PARTY_NOTICES.md` names a release and its jars. The plan job refuses a SNAPSHOT engine for a final or post version. A release run links a snapshot only for a `.devN` tag, and only the one pinned in `scripts/dev_engine_pin.json` (see xref:development/release.adoc[Release]); every other snapshot is refused, so a final or post release never depends on one. The `legs` input of a manual run chooses all four platforms (`full`, the default) or the one platform and one Python of a pull request (`pull-request`).
 
 The dev-engine bump after each release, described in xref:development/release.adoc[Release], moves `DEV_ENGINE` to the new release and closes the gap until upstream publishes the next one.