I accidentally got some bloop cruft in the commit, so would redo it before it could be viable for merge.

Do you think we target these changes for the mainline 3.x, the semi-compatible 4.x line, or the break the world 5.x line? The sheer number of changes and removal of attention to persistence biases me a bit in the direction of 5.x.

I vote for "clean it up" in 4, then Scala3 in 5, so I'm infavor of removing persistence etc. in 4.

I would agree with Andreak. 4 is a straight-up breaking change wrt to persistence, but otherwise basically just getting to most recent dependencies. Then 5 is scala3 + whatever other features anyone is motivated to support, such as the json macros.

I'm supportive of this approach. I'm going to change the target branch to the lift-4.x line for now.

Once the bloop changes are cleaned up I think this will be g2g.

deblooped.

I believe you just need to push a commit adding your name and email as a signature on this document: https://github.com/lift/framework/blob/master/contributors.md

Confirming all the tests are passing as long as I run it in Java 11 - however given that it's 2024, we have a few LTS releases ahead of that, and this is a major version bump anyhow - I'm fine with that.

Merging!

+1 for java21 as the minimum for Lift4.

Oups, late on the game but for some contexte: I'm extremelly interested by that PR and a Lift 4 version that is just upgrading to Java 17 and servlet 4/5.
I was the one asking for it on the mailing list because we are currently blocked in our Spring Security upgrade due to the servlet namespace. But we would like to not have other breaking changes in the core/web parts. So the proposition by @pabloazul seems good with us.
I'm going to try that version and report any worthy feedback.
In the meantime, THANK YOU SO MUCH for that PR. It was more involved than what I was thinking it would be. (the type ascription part is not the one I love the much with scala 3)

Let's try from the right account this time!

Unless folks feel suuuuper strongly, I'd prefer we aim for Java 11+ for Lift 4 and Java 17+ for Lift 5. Mostly just because Lift 3 supports all the way back to Java 8 and I feel a bit bad for moving multiple LTS releases of Java in a single Lift major bump. 😅

@farmdawgnation : no big feeling on jdk11 vs jdk17. It looks from my point of view that JDK8 was a specificity, but once people migrated away from it, they somehow followed JDK updates.
And so why not JDK21 directly cc @andreak ? Just because we're still in the "around 2 years of transition for ecosystem to migrate to the next version when out". Or just "support the last 2 LTS". Typically in Rudder, we need to support Linux distrib that were released before JDK21 (and make things complicated to have it).
But if lift want to support JDK11 in Lift4, and given the goal of that version to break as little things as possible while modernizing the stack, it looks good to me too.

@pabloazul : the good new: it works perfectly and I was triavialy able to update Rudder to servlet 5 / jetty11.
The bad news: above report is only based on compilation and unit tests, because updating to Spring 6 is an other story, and totally broken for now, so the app doesn't start (well, it starts but fail as soon as we reach the authentication bootstrapping).
So it seems OK like that, and I'm going to sacrifices things to make Spring God happy.

OK, after a bit more testing, everything is working fine on my side. We would be extremely glad to have a version alpha1 of lift 4 published as it stands now, it would greatly facilitate migration and more testing.

Thank you all for the amazing work ! It's unbloking a major topic for us.

Hey @fanf - Sorry for not replying sooner, but acknowledged. I can probably get an M1 build spin up sometime this week. Going to try for today but my kids may have other plans. 😂