Version range filters in getChanges compare versions as strings

Problem

The getChanges macro accepts comparison prefixes on its versions parameter (>=, <=, >, <). Code/Change/GetChangesMacro turns these into plain SQL comparisons against entries.version:

#set ($discard = $clauses.add("${class}.${name} >= :${name}${foreach.count}"))

EntryClass.version is a DBListClass with multiSelect=0, i.e. a StringProperty stored in a VARCHAR column. The comparison is therefore lexicographic, not version-aware.

Consequence

A report silently returns a wrong, quietly truncated list of changes — it renders successfully, so nothing signals the problem:

• versions=">=9.0" excludes every 10.x-17.x release note (because "10.0" < "9.0" as strings).
• versions="<=10.0" excludes 2.0.

The outcome additionally depends on the database collation.

Notes

RN-72 fixed these operators at the boundary level (the equal case is now included) but the comparison semantics were never addressed. A fix needs either a normalised sortable value stored alongside the version (zero-padded), or the range comparison done after the query.

Found by a review of the code base; the versions operators are covered by GetChangesMacroPageTest, which asserts the generated XWQL but not the ordering semantics.