Announcing Lucee (final) and (hotfix)


Hello again Lucites. How’s things? Anything much going on lately? Rumor has it there are some headlines, or some such, but you couldn’t prove it by the Lucee dev team, because we just continue to crank out builds. Today, we’re announcing two final releases, plus a new sprint that will produce the next Release Candidate in a couple of weeks, or so. (FYI, I get credit for 3 jokes in one there–an I Love Lucee reference, coronavirus, and a dog. So perilous to try to be humorous at a time like this. I thought that was a pretty good effort!)

First, here’s a big picture update about recent development efforts. First, regarding the previous final release of Lucee––most folks by now have noticed there was a “silent release,” and in fact the latest final build of 5.3.4 is This was actually a hotfix, which ended up being related to some especially challenging ongoing bugs, which we’d thought we’d fixed by, but hadn’t. Thus, working closely with the community, and in particular a couple of member organizations who really help a ton with iterative testing, we decided the fixes were important enough to warrant a hotfix release, which came out very quickly (~ 2 weeks) after the original final build. So quickly, in fact, that we got behind on a formal post about it (that’s on me; apologies!). In parallel, we were working on finalizing the latest 5.3.5 release candidate. We found some regressions during the RC period, and in addition, many of the 5.3.4 hotfixes made it into 5.3.5 as well. Details on both final builds are below.

In effect, what happened with both of these final releases is that we had moved into the shorter, more-iterative sprint schedule we’re planning for 2020. Both final releases came out of focused, 2- to 3-week sprints, and we’ve got a lot more stability in place now. That’s a good sign of how this new sprint plan will work better for Lucee, as compared to the enormous sprints we’d been doing previously.

Here are the tickets for regressions/fixes that came up during the 5.3.5 RC period, beyond the original Release Candidate ticket list:

Next, if you’d like to review what went into that hotfix, here’s that ticket list.

If you’ve been tracking tickets in recent sprints/releases, and in particular if you’ve had any performance or stability problems with 5.3.x releases, we strongly recommend that you give a test. We’ve seen dramatically improved results in real-world testing so far.

Finally, the 5.3.6 sprint is underway, and will produce the next release candidate in 2-3 weeks.

As always, thanks for listening!

Global Product Manager


After upgrading to, CommandBox stops producing ORM SQL log. I tried the latest snapshot ( too, no SQL log either. Once downgraded to, SQL log reappears.

Do you happen to know how to get it fixed on newer versions than

To be clear, CommandBox itself doesn’t do anything with ORM logging. That’s Lucee :slight_smile: To clarify, are you talking about a dedicated log file for ORM in the server or web context or are you talking about the ORM logging that shows up in the console output?

Do you happen to know how to get it fixed

The generally-accepted manner of getting bugs fixed is to enter a ticket. Provide a stand-alone test case that shows the issue and tag the ticket as a regression if you feel it is one.

Can we get some love on the PR front before 5.3.6 goes RC?

Lucee has over 165 open requests

I have done a heap of work on improvements to error messages,
all broken up into smaller PRs as requested, but it’s getting hard to do
any more as it’s hard to track what’s already been fixed

Grammar aside, two important/useful ones
varscoping speedup for extension thumbnails

modern debugging: add client side sorting for tables

The PDF extension has 7 open PRs

The image extension has 4 open PRs


Are you talking about just enabling the ORM logs via Application.cfc? Or the log4j approach?


If we’re adding PRs that we’re waiting on:

Hi Zac/all. Yes, getting caught up on PRs is an ongoing problem for us. With the recent increase in dev team resources, our eventual plan is to get current. We did discuss this specifically in this week’s standup, so it’s at least getting some planning attention behind the scenes, but as always it’s a resource problem for us.

@IamSigmund is there any way for us to find out what commits were involved in the move from 5.3.4+80 to the 5.3.4-SNAPSHOT+85?

1 Like

try this


Thanks @Zac_Spitzer! I think that’s just what I was looking for.