MariaDB extension version numbers

OS: Windows
Java: Temurin jdk-11.0.17+8
Lucee: and

I’m not sure when this started happening but my Server Admin UIs are giving incorrect information about the MariaDB extension, of which I’m the current maintainer via Forgebox.


It says I need to update from 3.0.7 to, but I can tell you that there is no version I use SemVer and 3.0.7 is the latest release.

The version numbers of other Available versions are also wrong on the extension page itself:

Has some rule been introduced that extension versions must be in N.N.N.N format?

@Julian_Halliwell created a new ticket for this issue in JIRA: [LDEV-4378] - Lucee


I see this with a few extensions. At first I thought that Lucee must’ve changed something in the admin related to extension versions, but even dropping back to older versions I am seeing this issue. Now I wonder if it is that changed something recently?

@Julian_Halliwell there is a difference in versions on the MANIFEST.MF (3.7.0) and forgebox ( for the MariaDB extension, it cause this issue.

Thanks, Pothys. So as Andrew suggests, this appears to be an issue with Forgebox, specifically the REST API since the box.json has the correct version. @bdw429s can you shed any light on this?


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:

Basically, Lucee’s admin doesn’t know what to do with versions in the format of


like is common on ForgeBox. All of the core extensions use the format of

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 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 when comparing versions and realize it’s the same version.

Actually, I take that back-- doing so would break the sorting of some of our extensions again :confused: 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)

But if only some of the versions had a 4th digit and others didn’t here, Lucee wouldn’t sort them correctly.


The standardization of always having 4 digits is actually what makes Lucee work correctly in this scenario. I think I’m still back at my original wish which is for Lucee to fix its semver parsing to see 1.2.3 having the same semver value as

Thanks Brad. So as someone with an extension on Forgebox, what should we, specifically, do now to help ameliorate this situation for people? Or should we wait for Ortus/Lucee to hash it out first?

That’s a great question, lol. The change ForgeBox made was expected to be backwards compatible! The big issue is-- even if tomorrow, Lucee agrees with me and vows to change their parsing-- how many months before that is developed, let alone released? And it only will affect updated installs of Lucee! I can update ForgeBox, push a button on my CI/CD server, and roll out another change to the API any time I want. (mostly) The only hang up is I’m not sure what behavior I can change to which will work in both cases. Like I said, this is “danged if we do and danged if we don’t” because the presence OR absense of the 4th digit explicitly seems to break different scenarios.

You basically won’t be affected currently if you always use a build number (4th digit) across the board. But I also realize it’s not a trivial task to go back and change artifacts and ForgeBox versions for previous releases. I guess, new versions of your extensions going forward having a 4 part number in their manifest should at least make new versions recognize that they are the version installed.

As I think you’ve realized, it isn’t unfortunately. This Dockerfile which was working, now breaks because it can’t download the MariaDB extension because 3.0.7 is no longer a valid version.

FROM ortussolutions/commandbox

ENV LUCEE_EXTENSIONS="F2FA5DB2-0C27-499C-B1171D2D812FDAF9;name=MariaDB;version=3.0.7"

Ugh, I didn’t realize it affecting that as well. From the original post, it was just creating an annoyance in the admin. I’ve put a fix into ForgeBox to only include the 4th digit if the version number in ForgeBox actually has a buildID. so 1.2.3+4 will still be but 5.6.7 won’t change.

I’m discussing with @lmajano when we can get it deployed.

1 Like

Ok, we’ve released a hotfix update to ForgeBox to no longer include the 4th digit for versions on ForgeBox who don’t already have a buildID. This does not absolve Lucee of it’s need to implement improvements on how it parses version numbers, but it should make stuff that worked before work again. Please let me know if there are still issues.