test with pekko 1.2.0

[pjfanning]

just experimenting with staging version of this release (an RC being voted on)

[pjfanning]

@He-Pin is the idea that pekko-http 1.3.0 uses pekko core 1.2 as its minimum supported version? I'm neutral. I don't especially mind leaving the depenency on 1.1 with the knowledge that 1.2 works too.

[He-Pin]

@pjfanning I think so, because Play will use Pekko 1.2.0 and Pekko http next anyway, we should make Pekko http use 1.2.0 and remove all usage of the deprecated methods.

And we deleted nothing in Pekko 1.2.0, so that's shold be fine.

[pjfanning]

@raboof what do you think of us making pekko-http 1.3.0 (next minor release) have a defined dependency on pekko (core) 1.2.0? It's not necessary since the code still works with Pekko 1.1.x but it might be useful to suggest that users upgrade.

[He-Pin]

@mkurz wdyt?

[mkurz]

Play will definitely bump Pekko to 1.2.x and Pekko Http to 1.3.x (assuming it will be released within the next couple of weeks) for it's next major release. In the end for Play it's not really relevant if Pekko Http itself depends on Pekko 1.1 or 1.2 since we just force Pekko 1.2 anyway. (assuming pekko-http next works with both 1.1 and 1.2 which is what you say in this thread).

Not sure what what you want to do, depending on one or the another should be fine for users. I would guess someone who upgrades Pekko Http to 1.3 will also likely upgrade Pekko to 1.2 anyway.
I think you have more insights here than me to make the right decision.

[He-Pin]

Because many methods have been deprecated in 1.2, if they are not migrated to the replacement methods, compilation in strict mode will cause errors, which is not good for users in any way. Why not compile with the latest version and fix all the problems in this new version, and maintain it well as the last version supporting Java 8?

So I'm +1 on migrating to Pekko 1.2.0

[raboof]

@raboof what do you think of us making pekko-http 1.3.0 (next minor release) have a defined dependency on pekko (core) 1.2.0? It's not necessary since the code still works with Pekko 1.1.x

Traditionally we haven't, because that is most flexible for users: if pekko-http depends on 1.1.x you can use it with either 1.1.x or 1.2.x, but if pekko-http depends on 1.2.x then you can no longer assume it will work with 1.1.x (since we provide backwards but not forwards compatibility). We documented this in https://pekko.apache.org/docs/pekko/current/project/downstream-upgrade-strategy.html

it might be useful to suggest that users upgrade.

I think traditionally we 'suggested' that by updating the 'bom' artifact (though I don't think I ever used that myself...).

I like the tendency to be more proactive in nudging users to upgrade. For that reason I'm in favor of updating the version here, even if it's not 'needed'. We should probably tweak the wording in https://pekko.apache.org/docs/pekko/current/project/downstream-upgrade-strategy.html to reflect that, then.

[He-Pin]

Akka once did that for commercial support, but as an open-source project, I think now we should make it simpler for both users and maintainers.

[pjfanning]

@raboof the pekko-bom exposes the same dependency versions as the jar pom files.
I have https://github.com/pjfanning/pekko-libraries-bom but I don't think many users use that. sbt requires use of https://github.com/heremaps/here-sbt-bom to support Maven BOMs.

Since we don't need anything from pekko 1.2, I don't think we should merge this PR.

[He-Pin]

But the users are using Pekko 1.2.0, and now, Pekko grpc and Pekko http are using many deprecated methods.

[pjfanning]

But the users are using Pekko 1.2.0, and now, Pekko grpc and Pekko http are using many deprecated methods.

This is why I want to get pekko 2.0.0-M1 released so that we can branch pekko-http etc and start working on 2.0.0 updates for those modules too. I already have a few PRs for pekko-http.