SOLR-18217: Add SemVer field that wraps a long field

[HoustonPutman]

https://issues.apache.org/jira/browse/SOLR-18217

This is a new fieldType that accepts a maximum 6-part version string, which is internally converted to a long. Each version part has a maximum value of 999. So the range is 0.0.0.0.0.0 - 999.999.999.999.999.999. This ensures that our maximum long conversion is roughly 2^60, so it should always fit.

AI Disclosure: Claude helped write this.

[dsmiley]

Neat

[publickeating]

Apologies that I don’t have much context on the source of the change—this caught my attention inadvertently, but this looks like it would result in incorrect assumptions about the value in the field. The implementation appears to be a practical implementation of SemVer, but not an exact implementation.

These are all valid SemVer from the Semantic Versioning website:

• 1.0.0-alpha (lower precedence than 1.0.0)
• 1.0.0-alpha.1 (greater precedence than 1.0.0-alpha)
• 1.0.0-0.3.7
• 1.0.0-x.7.z.92
• 1.0.0-x-y-z.--
• 1.0.0-alpha+001
• 1.0.0+20130313144700
• 1.0.0-beta+exp.sha.5114f85
• 1.0.0+21AF26D3----117B344092BD

Maybe the name and docs should attempt to reflect this difference? Ideally, there’d be a globally adopted standard, “NatNumSemVer” for “Semantic Versioning using Natural Numbers”, which only supports decimal separated monotonically increasing positive integers and you could name your field accordingly…

Or maybe the implementation should support full SemVer per the spec? — and punt the sort and range comparison problem down the road?