diff --git a/README.md b/README.md index 631b796..e479dbc 100644 --- a/README.md +++ 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. +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). ## Citation diff --git a/docs/modules/ROOT/pages/development/ci.adoc b/docs/modules/ROOT/pages/development/ci.adoc index 0f4aa0c..a128917 100644 --- a/docs/modules/ROOT/pages/development/ci.adoc +++ b/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 -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.