diff --git a/docs/modules/ROOT/pages/how-to/bulk-loads.adoc b/docs/modules/ROOT/pages/how-to/bulk-loads.adoc
index ace65a4..8acbadf 100644
--- a/docs/modules/ROOT/pages/how-to/bulk-loads.adoc
+++ b/docs/modules/ROOT/pages/how-to/bulk-loads.adoc
@@ -164,7 +164,7 @@ An engine-level Java run of the same shape confirms the split: after 2,000 round
 
 The engine-level Java run, repeated on the merge of the fix, kept the batch's edge bucket at 4 pages after 2,000 rounds, the same as `newEdge` in ordinary transactions, against 2,000 pages on its parent (https://github.com/ArcadeData/arcadedb/issues/10746#issuecomment-6462354150[verification on #10746]).
 
-From 26.11.1 on, `graph_batch()` is fine for a workload that deletes and inserts again. On a `26.11.1.devN` pre-release, write the edges with SQL (`CREATE EDGE`) or with `Vertex.new_edge` inside `db.transaction()` instead. Both stayed flat in the measurement (0.25 MiB in the table).
+From 26.11.1 on, `graph_batch()` is fine for a workload that deletes and inserts again. On an engine older than 26.11.1, write the edges with SQL (`CREATE EDGE`) or with `Vertex.new_edge` inside `db.transaction()` instead. Both stayed flat in the measurement (0.25 MiB in the table).
 
 == If a graph batch is interrupted