Prepping for 3.5

[Matt Farmer]

Hey everyone,

I just opened a PR for the last bit of work we needed to get a Lift build that fully supports Scala 2.13: https://github.com/lift/framework/pull/1988

Once that's in my plan is to do a bit of build file cleanup and release Lift 3.5 shortly thereafter.

As a part of that, I'd like us to consider some deprecations for things to rip out in a Lift 4.0 release. The Framework's size hails from a time where there was a lot more human power behind the maintenance of it. If we're going to continue maintaining it with the resources we have, I think that means we need to seriously consider simplifying things.

In particular:

• Lift Modules is currently it's own org of many-repos. In a world where we've got many maintainers of different modules and didn't want to give them access to the lift org, that made sense. However since we made that migration (1) that's no longer the case and (2) GitHub permissions have gotten better.
  • To help with maintenance I'm proposing we resurrect lift/modules and combine all the various, existing repositories back into a monorepo.
• We have three DB layers in play. I'm proposing we split all the various DB related things into Lift Modules and start planning for that change to occur in Lift 4.
  • Reasoning here is that for the most part I've always used other persistence connections with Lift when I've done it, and I think generally the popularity of ORM-style connections are falling out of favor.
  • Mapper as a whole should likely be deprecated in favor of record?
  • The squeryl-record module has not been updated in some time and squeryl itself seems to be in maintenance mode. Proposing we mark it as deprecated as well.
  • This will reduce the core framework footprint significantly and let folks interested in record/mapper development operate independently of the main framework however they like.
• scalaz is mostly in maintenance mode. Proposing we mark json-scalaz7 deprecated.

Let me know what y'all think.

Cheers,

Matt

[Tim Nelson]

I agree with most of that. The only thing I would change is to keep Mapper. The only SQL backend that's been implemented for Record is squeryl-record and if we're going to deprecate that, which I agree we should, there would be no alternative to mapper. Plus, it's probably the most used of the persistence modules.

I would probably also be in agreement to deprecate lift-mongodb and lift-mongodb-record, as it feels like I'm the only one still using it and I could maintain that on my own.

Tim

[Carlos Saltos]

Thank you Matt for the PR ... looking forward for Lift 4.0 !!

Best regards,

Carlos Saltos

[Eik Aab]

In case of Mapper I agree with Tim.

Cheers

Eik

[Matt Farmer]

Lol. If it's any indication of the kind of year I've had I'm just now revisiting the idea of releasing a 3.5 because of the recent replies here. I'm going to work on spinning out an RC build today with the changes we've made since 3.4.

[Andreas Joseph Krogh]

På mandag 23. august 2021 kl. 18:51:12, skrev Matt Farmer <ma...@frmr.me>:

Lol. If it's any indication of the kind of year I've had I'm just now revisiting the idea of releasing a 3.5 because of the recent replies here. I'm going to work on spinning out an RC build today with the changes we've made since 3.4.

 

🎸

 

--

Andreas Joseph Krogh

CTO / Partner - Visena AS

Mobile: +47 909 56 963

and...@visena.com

www.visena.com