Greetings, Lucites! Time for the second Lucee release in the past 10 days!
Astute observers know that over the past year+ our releases are now spaced farther apart. However, due to the extra work that went into the final release of 5.3.1 (more testing, 2 Release Candidate periods, more regressions found and fixed, etc.), that release got pushed into this week’s 5.3.2 Release Candidate. Read on for all the details!
(Chemical formula for Poly(methyl methacrylate), sometimes commercially known as Lucite; Or, sort of looks like a Lucee developer on Monday morning .)
Today we’re announcing Lucee 5.3.2-RC (5.3.2.74), following the completion of the March sprint. As we noted when shipping the final build of 5.3.1, the 5.3.1 development cycle was, overall, long and loaded with development work! Still, we stuck with our plans for the March sprint, in order to stay on schedule. Right on the heels of the busiest-ever development cycle with 5.3.1 (first-ever 3-digit build number–5.3.1.102!), today’s 5.3.2-RC covers another64 tickets! Here’s the summary:
It’s available now at the downloads site. Thanks in advance for as much testing and feedback as you can muster!
5.3.2 will become a final release at the beginning of May, and then next up on the development docket is the May sprint, which will produce Lucee 5.3.3-RC. Still room for your favorite ticket(s), so as always keep up with ticket comments, upvoting, etc.
The “fixed tickets” list contains a ticket that is not fixed but is erroneously marked as fixed on the tracker. We have submitted PRs for this and a related issue and commented that the “deployed” fixes are not fixed, but received no response.
I appreciate that the subject area (old CF compatibility tags) is very mundane and of limited use, but having gone to the trouble of fixing these issues and submitting those fixes to Lucee, we would have no objection if our fixes were rejected in favor of a different solution; or if the whole subject were deemed not worthy of attention and ignored. But marking them as fixed when they are not and then including them in a release announcement shows poorly, not to mention taking up a lot of time when we go and remove our fixes from our Docker build process only to find that we have to put them back.
Hi @Samuel_W_Knowlton. Thanks for the heads-up. Upon quick glance, I can’t figure out what’s going on here, so let me discuss with the development team, and we’ll get back to you.
Hi @Samuel_W_Knowlton. Following up on 2100, it looks like the second PR got accepted, and passed, and this is deployed in both 5.3.1 and 5.3.2. Let me know if you still have questions!
Hi @IamSigmund – the second PR was never accepted, and unless the fix was deployed within the last couple of weeks, it wasn’t in either 5.3.1 or 5.3.2 when we checked before Into the Box as we have a custom build process that currently merges that fix in, and when we removed that step, it broke again.
Please either accept the PR that resolves these tickets or remove the tickets from the list of fixed issues for 5.2 and 5.3. I get that legacy support for this tag is not a big issue for anyone but this has been marked fixed for months now and we have brought it to your attention on several occasions.
Hi @Samuel_W_Knowlton. As I mentioned in the CFML Slack, we’re still investigating. For the record, this didn’t make an agenda in a dev team meeting until May 13, so we’ve only really been looking at it for a couple of weeks. The reason it’s taking some time is because we were already in the midst of both the May sprint and the 5.3.2 final release. Thanks for your patience. @micstriit@isapir@cfmitrah.