Lift 3.0?

[riveramj]

I tried to build a project with lift 3.0.1 and lift-formality and it couldnt bind. When will this support lift 3?

[pdyraga]

What's the current status of Lift3 support? I see build.sbt refers to Lift3 now but I am not sure if everything is expected to work fine or if there are any potential issues lurking in the dark.

[Shadowfiend]

It's not been tested in depth, but most of the functionality lift-formality uses is orthogonal to the changes in Lift 3 so I don't anticipate any serious issues cropping up.

[Shadowfiend]

I do need to check if there's a published 1.0 build for Lift 3, however.

[pdyraga]

The 1.0-RELEASE was for Lift 2.6 only, 1.1-SNAPSHOT available on central is from June currently so I guess it's a build for 3.0. The recent version bump for 3.1 wasn't published yet.

I am wondering if we shouldn't have 3.0_2.11-1.1.0-SNAPSHOT and 3.1_2.11-1.1.0-SNAPSHOT versions published separately. If so, I can spin a PR.

[Shadowfiend]

Hypothetically, the 3.0 snapshot should work for any patch** versions of 3.0. Same for 3.1.

Would love a PR!

[Shadowfiend]

Also is that backwards, should be 1.1.0_3.0_2.11-SNAPSHOT*?

[pdyraga]

Scala / Lift versions are parts of a name so the artifact version goes later. For example:
https://oss.sonatype.org/content/repositories/releases/net/liftmodules/widgets_3.1_2.12/1.5.0/
https://oss.sonatype.org/content/repositories/releases/net/liftmodules/messagebus_3.1_2.11/1.0/

Just to clarify: 3.0 snapshot should work for any minor version of 3.0 and same for 3.1 but my understanding is that dependency built for 3.1 not necessarily work for a project built for 3.0, plus, we can have a number of transitive dependency issues.

[Shadowfiend]

Correct on 3.0 vs 3.1 not being guaranteed mutually compatible. Transitive dependencies should not change in patch versions.

[Shadowfiend]

Also, yep, right you are on the name. So weird to see the version listed without the artifact name that it scrambled my brain haha.

[pdyraga]

Here we go: #27

I think that having this PR in we can cherry-pick 78a4f75 and publish snapshot versions for 3.0 and then publish a version for 3.1 from HEAD. 78a4f75 is just before 3.1 version bump and there were no other changes in between. What do you think?

[Shadowfiend]

One question that occurs to me is whether anyone actually needs it for Lift 3.0... Usage is low enough that we may just be able to do a full release for 3.1 and leave 3.0 behind for now, unless someone explicitly requests it.

[pdyraga]

whether anyone actually needs it for Lift 3.0

I need it :)

I am currently migrating our 2.6-based project and my first thought was to migrate it straight to 3.1 too. Unfortunately, it's not possible due to conflicts of some transitive dependencies and some of our clojure code. What's more, there are some code duplicates between our codebase and Lift 3.1 - some pieces were incorporated from our project into 3.1 but they evolved separately in a meantime.
Since I already have to fix a number of problems related to 3.0 migration, the decision is to upgrade gradually. 3.0 first and then 3.1.

[Shadowfiend]

Ah-hah! Gotcha :)

[Shadowfiend]

I think I'll do a 1.1.0 final release for this.

[Shadowfiend]

Notable, I'm seeing this:

…/lift-formality/build.sbt:12: warning: `<<=` operator is deprecated. Use `key := { x.value }` or `key ~= (old => { newValue })`

[Shadowfiend]

(sbt 0.13.17-RC1 though, because I'm building on Java 9.)

[Shadowfiend]

Ok, I published 1.1.0-SNAPSHOT for 3.0 and 3.1. If you can confirm that the 3.0 release behaves as expected, I can do the 1.1.0 final bump.

[pdyraga]

…/lift-formality/build.sbt:12: warning: <<= operator is deprecated. Use key := { x.value } or key ~= (old => { newValue })

Ouch, right... <<= is deprecated now. Maybe we can switch it in the #28?

I published 1.1.0-SNAPSHOT for 3.0 and 3.1.

❤️ Thanks!

[Shadowfiend]

I think we'll get 1.1.0 out the door then work on 2.12.x, sbt 1.0, and that deprecation warning. Might as well bundle it all up.