Year-End Development Update: Announcing Lucee 5.3.4.73 (Release Candidate 2) and Final 2019 Sprint

Season’s Greetings, Lucites! On behalf of eveyone at LAS, here’s hoping you’re all having a great holiday season! Hopefully Lucee has been more nice than naughty for you this year, but whatever the case, we’re ever-focused on sprinting towards better and better releases. On that note, today we’ve got some announcements to make.

First, as you’ve probably noticed, this has been an especially long Release Candidate period since we shipped 5.3.4.54 (RC). This was due in part to typical annual demands of the CFCamp conference in Germany, for which we spent some significant time working on the roadmap for the next major and minor versions of Lucee, creating some test builds for demo purposes, etc. But more importantly, it’s also due to an uptick in regressions over the past two releases (5.3.3.62 (final) 5.3.4.54 (RC)). We spent a lot more time than anticipated working with ticket reporters, identifying regression sources, and of course discussing/debating then implementing and testing fixes. We identified 14 tickets that needed urgent attention, and about half of the problems discovered during the RC period were in 5.3.4.54 (roughly the other half were in 5.3.3.62), and since that’s too high a number of regressions in our opinion, we’ve accordingly decided to build a second 5.3.4 Release Candidate (5.3.4.73), which is available today. We plan to make this a final build over the next couple of weeks, so since this will be a much shorter RC period than is typical, please help with testing RC2 today, in particular if you’ve been active in any of the tickets covered. Here’s the 5.3.4.73 (RC2) list:

Next, if a ticket you’ve been following isn’t covered in this new RC, then good news–we’re also announcing the final 2019 sprint, which officially starts today. This sprint will overlap from December to January, and will produce a 5.3.5 Release Candidate. Here’s a look at the list of tickets selected for this sprint. Please note that this list may shrink in size as the sprint unfolds into January. This relates to a new sprint strategy we’re experimenting with for 2020. Read on below.

Finally, a quick note about the 2020 development schedule. As readers of this august publication know, I was pretty vocal throughout the year about the increasing number of regressions we’ve been seeing, increasingly difficult sprint planning, and related complaints. The cause of all of this is clear, and even expected–the demands on the development team have been steadily increasing, both in volume and complexity. This is good news, really, as it means Lucee adoption is increasing, and the use cases for Lucee are increasingly complex. Exactly what we want for a development platform! However, it also means that, while we scale up the development team to handle the increased load, we’ve got to get smarter about how we manage things in the meantime. So, for 2020, we’re going to be doing a larger number of shorter sprints. We’re thinking something along the lines of targeted, 2-week sprints, which will allow us to iterate more rapidly, but while limiting regressions and maintaining a high build quality.

After the December-January sprint is done, we’ll share detailed info about the 2020 development schedule. Meantime, happy coding, Happy Holidays, and thanks for listening!

Best,
Patrick

10 Likes

Thank you for all the hard work!

2 Likes

Awesome update! Thank you so much for your efforts amidst a holiday season.

1 Like

Thanks, Patrick. Merry Christmas!

1 Like

Thanks for the update! Really looking forward to finally be able to upgrade, hopefully.
Doing a second RC is a logical and very good decision, kudos for that!

Imho Lucee should start a long-term support (LTS) version in 2020, where only bug fixes are updated in, no new features.
Because on the current road, “stable releases” are actually beta state :frowning:

I do appreciate all the effort: I :heart: Lucee!

4 Likes

Thanks to Patrick and the rest of the core team. Y’all are doing a great job managing a big project with a small team!

1 Like

+1 on LTS. Our client’s don’t like being told “we are doing a server update again…”

1 Like

Completely agree on LTS. That’s definitely on our list of improvements to make in 2020, among others. Thanks to @frinky and @ObiWebKenobi for the suggestion!

Reflecting on the last few releases, it’s seems that the last commit before the first RC is often extremely problematic, something to consider.

While I understand why they were necessary, trying to avoid such changes just before the RC would be better.

Some of us test the bleeding edge snapshots, catching problems before we move to a RC release, but these last minute fixes often don’t leave us enough time.

With RCs, a lot more people start testing and all encounter the same problem(s). This contributes to upgrade fatigue.

LTS sounds really good, 2 week sprints worry me in terms of exacerbating the upgrade fatigue problem TBQH and I hope we never end up at an iOS type situation where buggy code gets shipped due to schedule

I hope any change to the overall process takes into consideration how frustrating it is for users having to wait 2-3 months for example for a one line fix for the admin…

Hey @Zac_Spitzer. Thanks for the comments. To clarify, the shorter sprints are intended to fix exactly the problems you’re highlighting here–buggy releases (due to way too many tickets in the sprints), and long waits for newer releases. A further clarification–these won’t be every 2 weeks! (Perish the thought!) It’s just that, overall, we’ll be doing a larger number of shorter sprints throughout the year, so we can ship better software faster/more frequently.

3 Likes

Still not possible to update classes (such as the Java AWS SDK) that Lucee ships with using this.javaSettings and giving your own updated ones (expecting to get them back via createObject(‘java’) : https://luceeserver.atlassian.net/browse/LDEV-2132

This is a clear regression in 5.3.2 compared to earlier, as well as expected behavior. It blocks our upgrade from 5.2.