Mid-Year Development Update

Hi Lucites! I hope everyone is having a great summer. As we’re now into the second half of 2019, I wanted to send along a quick status update to the community.

The July sprint is underway, and we’ll be wrapping that up the week of August 5, and that will produce an RC for Lucee 5.3.4. According to the 2019 development schedule, we’ve got 2 more sprints left this year, followed by 2 more RC/planning periods. However, for a few different reasons, we may tweak that a bit.

First and foremost, 2019 has seen the most torrid development pace for us in several years, since I took the post as Product Manager. Probably the best example was the 5.3 release that went through so many different builds it ended up with a 3-digit build number, a first for Lucee. While we’re proud of having shipped that much code this year, quality is absolutely more important to us than quantity. And, as we’ve been discussing with some especially active community members, and also amongst some of the member organizations (who tend to have some of the larger and most complex Lucee installations), we’re seeing some slippage when it comes to our quality control. Specifically, we’re seeing a slight increase in regressions, and also in a few cases of missed coverage on the part of our testing efforts. While these are still a tiny percentage of the overall production of our small but mighty development team, we are nonetheless going to be taking a closer look at this in the coming weeks and months.

There’s actually a bit of good news in this. It’s a sign of the increasing adoption of Lucee, and along with this an increase in the size and complexity of applications being built with it. Demands are at an all-time high for prioritization of Lucee development across a widening range of use cases. And this is coming not just from the community at large, but we’re also seeing an increase in requests for sponsored (paid) development, on the part of both member and non-member organizations.

We’re grappling with ORM, Oracle, and everything in between!

In agile-speak, our velocity is too high. That’s right–we’re speeding. So we’re going to tap the brakes in August. If necessary, we’ll re-arrange the remaining development schedule to make sure our quality control stays high. Nothing is more important for Lucee. Beyond the monthly sprints, we also have Lucee 6 to attend to, so that too will be a factor in how we schedule the rest of the year.

In discussing this with some members of the community, there were some questions about the organizational side of Lucee, and we discovered there was some confusion about makeup of the Lucee team, so in case anyone else is wondering, I wanted to share some clarifying info.

Lucee remains a predominantly volunteer effort. Finance, marketing, business development (sales), product management (ahem), testing, tech support–these and related functions are 100% volunteer efforts. The primary expense for Lucee is the paid development team, but even this isn’t fully funded just yet, and much of Lucee core development is also a volunteer contribution.

Considering this, we are definitely “punching above our weight,” to borrow a phrase from boxing. It’s also important to remember if you see us take a punch or two, and maybe wobble a bit. If you’ve seen a regression sneak in, or a deployed fix miss your use case, not to worry–we’re aware, and we’ll make sure we correct.

Continuing the boxing analogy, my job as the PM (and also in my dual role as a board member, along with the rest of the board and member organizations) is to make sure we punch hard, and punch often. But we also need to make sure we’re “beefing up” Team Lucee, so that we can take on bigger and better challenges. That’s the focus as we head into the second half of 2019.

Finally, on a personal note, I’ll be away from my keyboard for a bit of vacation, returning Monday, August 5. So don’t worry if you don’t get a reply from me in the coming weeks. I’ll look forward to connecting with you all when I’m back.

Thanks for listening,



Thanks for everything you do for the community and I hope you have a great break




Thank you for your great update and ongoing efforts and have a great holiday! I hope to add two more sponsor companies in 2020 (mine and a close client’s). Thanks, Jonas



Hope you had a fantastic vacation.

I agree wholeheartedly with the quality over quantity approach. Keep up the great work!


1 Like

Thanks a lot Patrick for this good summary. Wish you good vacations

1 Like

Patrick, what kind of help do you need? I am not a java developer, but could maybe offer some other work for Lucee.

1 Like

I’d love to see some action on all the open PRs, especially the simpler ones.

1 Like

Definitely on our list of things to improve, Zac. Stay tuned.


Hi all. Another update from the dev squad. As we’ve done once or twice before in the past few years, we decided to extend the July sprint to be a 2-month sprint. Simply put, there’s just too much going on (not counting summer schedules, but that certainly hasn’t helped!), so we needed more dev time to get the next RC ready. We’ll be shipping that around the first week of September, and then we’ll see if perhaps we need a longer RC period, too (again, something we’ve done once or twice before), to make sure we’re caught up. Then, we’ll post more information about the development schedule to end the year, including what we can do with regard to Lucee 6. Stay tuned!

Thanks for the update @IamSigmund! I’ve been getting near-daily pressure from CommandBox users to get it running on Lucee 5.3 (which will finally unlock Java 11 support), including large govt clients who are literally 30 days out from totally dropping Java 8. I’m completely stuck on 5.3 regressions however and it’s been one step forward, one step back. (Ex, one major CFZip bug fixed only to introduce a new one). Is there anything I can do to help get Lucee 5.3 ready for CommandBox to use it? I’d hate to see another release come and go and still have blockers in place.

Here’s the list of the tickets I’ve put in related to it

Some of them are fixed. LDEV-2221 for example is marked fixed, but it isn’t. He just put in some logging and then marked it complete

The most serious one I can’t work around right now is probably LDEV-2320

1 Like

Clearing out the enormous back log of existing PRs would be really awesome…

Lots of good fixes just sitting idle

1 Like

I actually have 2320 on a near-term strike list for the dev team, but I’ll be sure to review the others as well.

1 Like

Yes, a deep dive on PRs is also on the strike list I just mentioned to Brad in my previous comment. We will make progress on that soon.

1 Like

the docs build process is currently broken with https://luceeserver.atlassian.net/browse/LDEV-2426

and we then can’t even import any changes until command box gets released for a new version as the build process relies on commandbox…

Yeah, that regression made it into the queue very quickly, and has already been triaged. Should be a quick(ish) fix.

FYI, I just tweaked the doc builds so they would run again by forcing Java 8. The issue still exists and will need addressed at some point to get them running on java 11, but the docs should at least be building again now.

i restarted a build but it still bombed, it’s showing up at java 11 still?

@Zackster Did you rebase the pull request branch to master like I said on the ticket? Just re-running a previous build will use the travis file as it was when the branch was created. You need to merge master into your branch to get the latest travis changes.

ok, got it working, thanks!

1 Like