diff --git a/docs/querying/datasource.md b/docs/querying/datasource.md
index d179d2b8594..0f033824e10 100644
--- a/docs/querying/datasource.md
+++ b/docs/querying/datasource.md
@@ -365,7 +365,7 @@ GROUP BY
 Join datasources allow you to do a SQL-style join of two datasources. Stacking joins on top of each other allows
 you to join arbitrarily many datasources.
 
-In Druid {{DRUIDVERSION}}, joins in native queries are implemented with a broadcast hash-join algorithm. This means
+Joins in native queries are implemented with a broadcast hash-join algorithm. This means
 that all datasources other than the leftmost "base" datasource must fit in memory. In native queries, the join condition
 must be an equality. In SQL, any join condition is accepted, but only equalities of a certain form
 (see [Joins in SQL](#joins-in-sql)) execute efficiently as part of a native join. For other kinds of conditions, planner will try
@@ -431,7 +431,7 @@ and how to detect it.
 3. One common reason for implicit subquery generation is if the types of the two halves of an equality do not match.
 For example, since lookup keys are always strings, the condition `druid.d JOIN lookup.l ON d.field = l.field` will
 perform best if `d.field` is a string.
-4. As of Druid {{DRUIDVERSION}}, the join operator must evaluate the condition for each row. In the future, we expect
+4. The join operator must evaluate the condition for each row. In the future, we expect
 to implement both early and deferred condition evaluation, which we expect to improve performance considerably for
 common use cases.
 5. Currently, Druid does not support pushing down predicates (condition and filter) past a Join (i.e. into