The weekly recap fell by the wayside a bit as I focused on actually working on Lift 3, so here comes a second attempt with what I hope will be a more manageable pace. I’ll be expounding on features a little less than I did in the weekly recaps; instead, the purpose of monthly recaps will simply be a brief overview of what happened in the previous month.

March

To fill the gap, I’ll start where the last Lift Weekly Recap left off. The month of March was pretty quiet: @farmdawgnation did some private variable name cleanups, while @dmclean82 fixed an issue with blank parameter values in MockHttpServletRequest, which we weren’t handling correctly. Meantime, I changed the default implementation of lift:with-resource-id to produce a cache-busting query-string that didn’t confuse our unmapped function warning. A little more detail on that: since 2.6-M1, Lift has emitted a warning in the logs whenever a parameter is passed to a page that looks like it should be bound to a function, but it isn’t. This helps diagnose situations where your page for some reason is trying to refer to a server-side function that has been garbage collected. However, the parameter that lift:with-resource-id added on the end of resources looked like it should be bound to a function, so it was emitting a warning. That no longer happens.

April

Technically that last one got merged in April, but who’s counting. Early in April, @rofreytag contributed a fix for stale database connection releasing, where stale connections would throw exceptions and mess up the connection release process. Additionally, @farmdawgnation contributed an Iterator[Box[T]]=>Box[List[T]] helper. This implicit conversion can turn any iterator of boxes into a FullList of the contained values if all of the contained boxes are Full, or a ParamFailure if any of the contained boxes are non-Full; the parameter of the ParamFailure is the original list of boxes.

April also marked the beginning of a big effort to clean up Lift 3. In particular, we started going through and systematically fixing compiler warnings, as well as stripping things that were deprecated in the 2.x series. We also started deprecating additional things that would be removed in Lift 3. This effort is still ongoing. As a result, Lift 2.6 gained deprecation warnings on anything using Lift’s old JSONParser, which was not built on lift-json, as well as a few additional warnings sprinkled throughout the codebase.

Last but not least, we started building the Scala 2.10 version of Lift 2.6 on Scala 2.10.4.

May also saw the landing of a lot of the warning cleanup work from April in Lift 3. Lift 3 now compiles with only 3 or 4 warnings, and should have no deprecated methods left. We also released Lift 3.0-M1, which is meant as a stable checkpoint for folks who had been using pre-release Lift 3 builds before we did the massive cleanup referenced above. This gives folks a stable point to anchor to until they get a chance to deal with the changes that the cleanup introduced.

Last but not least, we went through all open issues and assigned them milestones, closed them, or asked for clarification on them in preparation for future work.

Next

Phew! Hopefully it’s obvious we haven’t been sitting on our hands the past few months. June’s looking to be another packed month, with a 2.6-M4 milestone build coming up soon (the first milestone to support Scala 2.11), a bump to the minimum supported Scala version for Lift 3 to be Scala 2.11, Lift 3 support for sending comet actors down from AJAX requests, and a continuation of the attacks on outdated code in Lift 3.

Once Lift 2.6-M4 is released, we’ll be making another big change: the lift_30 branch will become the master branch in the Lift repository and most development focus will shift to Lift 3.0. Simultaneously, the current master branch will become a lift_26 branch, and Lift 2.6 will start moving towards its first release candidate.

Hope you have a great start of your summer, and see you again in July!