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. |
