Yes, this is a recent change in ForgeBox, and it was done on purpose to try and fix related issues where Lucee’s extension version sorting wasn’t sorting extensions in the correct order since it doesn’t speak the “3” digit versions and Lucee expects to get “4” digit versions. Here’s the ticket for the change which was spurred by Ortus’ Redis extension’s versions not showing in the correct order in Lucee’s admin:
https://ortussolutions.atlassian.net/browse/FORGEBOX-730
Basically, Lucee’s admin doesn’t know what to do with versions in the format of
1.2.3+4
like is common on ForgeBox. All of the core extensions use the format of
1.2.3.4
so the idea was to try and standardize all the versions coming back from ForgeBox’s Lucee provider API to be in the format of x.x.x.x with the hopes all versions would behave consistently. The generally-regarded behavior of semver libraries is to treat missing numbers as zeros, so 1 is the equivalent to 1.0.0 and 1.2 is the same as 1.2.0, etc. I would have therefore expected Lucee to treat 1.2.3 the same as 1.2.3.0 but Lucee doesn’t use any pre-built semver libraries that I know and has custom logic written to parse them, which is probably why it’s not treating them along the same line of expectations of mainstream libraries.
I could update ForgeBox’s API again (seems like we’re damned if we do, damned if we don’t…) to omit the 4th digit entirely if there is no build number, but I really feel like this boils down to Lucee not treating missing digits as zero which is the commonly accepted semver behavior.
Technically a semantic version is strictly disallowed from not containing all digits, but we’re in a gray area here of converting semantic versions between standards. These excerpts from npm semver apply to desugaring ranges, but I’d say it’s the most applicable standard to move from an a.b.c format to an a.b.c.d format. Basically missing numbers should be considered a zero for the sake of comparison.
A missing minor and patch values will desugar to zero
(from the Caret Range section of the doc)
If a partial version is provided as the first version in the inclusive range, then the missing pieces are replaced with zeroes.
(from the Hyphen Range section of the doc)
If Lucee followed this practice, it would “see” 3.0.7 as 3.0.7.0 when comparing versions and realize it’s the same version.
If you take a look at the versions on this example package, they don’t all use use a buildID in ForgeBox (which is acceptable from ForgeBox’s perspective)