release for scala 2.13.0-M5?

[pjfanning]

https://www.scala-lang.org/download/2.13.0-M4.html - has been released

Relates to #24507
Depends on scalatest/scalatest#1367: 3.0.6-SNAP1 should work

[raboof]

👍 - still blocked on https://github.com/scala/scala-java8-compat (scala/scala-java8-compat#97, scala/scala-java8-compat#110)

[xuwei-k]

• scala-java8-compat https://oss.sonatype.org/content/repositories/releases/org/scala-lang/modules/scala-java8-compat_2.13.0-M4/
• ssl-config added scala 2.13.0-M4 support lightbend/ssl-config#83
• scala-stm
• spray-json (only akka-docs project?) Scala 2.13.0-M4 spray/spray-json#263

[schmitch]

ssl-config has a 2.13.0-M4 release http://central.maven.org/maven2/com/typesafe/ssl-config-core_2.13.0-M4/0.2.4/.

[MasseGuillaume]

@raboof Is there anyone on the Akka team working on this? If not, I would like to do it. It would be a good occasion to battle test https://github.com/scala/scala-collection-compat and it's migration rules.

[xuwei-k]

Is there anyone on the Akka team working on this?

#25267

[raboof]

@MasseGuillaume as @xuwei-k linked we've started exploring a bit, but your help would be greatly appreciated!

[SethTisue]

checking in, anything we should be discussing here...?

[ktoso]

I'll check out status and report back

[ktoso]

Okey so the PRs above are in progress and we need to continue the work here.
I'm leaving this to @raboof to continue once he's back from vacation next week :)

[MasseGuillaume]

@ktoso I'm currently working on this. Not as fast as I could since we use this to validate our scala/scala-collection-compat project and increase the quality of our automatic migration rules. This is what I got out of this so far:

• Rewrite breakOut
• Rewrite col.to and col.to[CC] => col.to(CC)
• Rewrite Future.{onSuccess, OnFailure} => Future.onComplete
• Rewrite JavaConversion
• Rewrite from,to,until => range{From,To,Until}
• Rewrite domino foldRight and foldLeft patterns (/: and :\)
• Rewrite Traversable* to Iterable*

The only manual par remaining would be:

• Decide if a collection.Seq should be immutable or mutable. (Akka normally marks immutable.Seq)
• Custom collections (such as ByteString)

You can track my progress here: https://github.com/MasseGuillaume/akka/commits/2.13.0-M4

Unless you are blocked by this, I would say leave me at least 2 weeks, then I would definitively need your help for PR review, making unit tests pass.

[SethTisue]

I'm curious how close Guillaume's efforts got to something releasable. does the Akka team expect to be able to publish for M5 fairly soon after all your dependencies publish...?

[dwijnand]

Btw, I suggest https://github.com/SethTisue/akka/tree/community-build-2.13 as the branch to integrate.

[patriknw]

we can do another push next week

[pjfanning]

https://github.com/scala/scala-collection-compat have released a migration tool based on scalafix. This might be helpful. I tried it with the Slick codebase and it seems to do a pretty good job (but there is a reasonable amount of extra work needed after the run).

[raboof]

Yes, we are using this as well - but thanks for the pointer. It is indeed incredibly helpful, but as you mention there is still quite some extra work to be done, especially since we want to maintain binary incompatibility, and in some cases the migration tool will violate that.

[pjfanning]

@raboof I suspect that it won't be possible to be binary compatible and that you will need to do the changes on an akka 2.6 code line.

[raboof]

@pjfanning that would be quite disappointing. Can you give an example of a construct that you suspect cannot be handled in a binary compatible way?

[SethTisue]

dozens of libraries have now published for M4 and/or M5 and I don't think any have yet needed to break bincompat to do it. perhaps there are counterexamples, but it isn't the norm.

Akka is big and could well be an exception, but it's worth being optimistic about.

I wonder if MiMa still passes on 2.11.x/2.12.x when @MasseGuillaume's patches are applied.

[raboof]

(I plan to look into this more later this week, and indeed am so far optimistic, though it'll be some work to get it to 100%)

[pjfanning]

https://github.com/slick/slick/pull/1966/files - this is an example from applying the migration to Slick code base. Note that Traversable is replaced with Iterable, TraversableOnce is replaced with IterableOnce and that CanBuildFrom is replaced by Factory. It also introduces a dependency on the scala-collection-compat library.

[SethTisue]

thanks for the list. the libraries I've seen pull this off have used workarounds rather than make the changes you list. these workarounds typically involve using small amounts of Scala-version-specific source code.

[raboof]

@pjfanning since Traversable is still available on 2.13 (albeit deprecated), perhaps we could just switch those changes back when they happen in the API. If that is not possible, perhaps we can use the technique from https://github.com/scala/scala-collection-compat/blob/master/compat/src/main/scala-2.11_2.12/scala/collection/compat/PackageShared.scala#L151?

I'm not sure CanBuildFrom/Factory is used in the API in many cases, but the fact that on 2.11/2.12 Factory actually is a CanBuildFrom on 2.11 might help (https://github.com/scala/scala-collection-compat/blob/master/compat/src/main/scala-2.11_2.12/scala/collection/compat/PackageShared.scala#L19)

Adding the dependency on scala-collection-compat should not be a problem (as soon as the time is right to start promising binary compatibility for that library itself, of course)

[SethTisue]

Adding the dependency on scala-collection-compat should not be a problem

you might consider avoiding it if possible, though, since as we all know, mo dependencies mo problems, especially downstream. most library maintainers so far are choosing not to use it. (though again, Akka is the largest and complex migration that has been attempted yet, different considerations may apply.)

[raboof]

@SethTisue that's interesting - I would love to avoid it but got the impression that a big reason for the library to exist in the first place would be to allow cross-building code that uses CanBuildFrom on 2.12. Of course an alternative might be to duplicate such code and provide different implementations for 2.12 and 2.13, but that seems like a ton of work that the library was designed to alleviate.

[jrudolph]

Could it make sense for Akka to copy only parts from the compat library somewhere into our codebase (if it's mostly about avoiding dependencies)?

[SethTisue]

Of course an alternative might be to duplicate such code and provide different implementations for 2.12 and 2.13, but that seems like a ton of work

for at least some particular libraries it really hasn't been that bad, see e.g. @ashawley's:

• https://github.com/scala/scala-xml/blob/master/shared/src/main/scala-2.11-2.12/scala/xml/ScalaVersionSpecific.scala
• https://github.com/scala/scala-xml/blob/master/shared/src/main/scala-2.13/scala/xml/ScalaVersionSpecific.scala

this is an example of what I said above about "small amounts of Scala-version-specific source code"

Could it make sense for Akka to copy only parts from the compat library somewhere into our codebase (if it's mostly about avoiding dependencies)?

perhaps, yes. copy and paste can be better if the code involved isn't too long or involved.

[SethTisue]

@szeiger and @julienrf may have perspectives on this

[SethTisue]

should this be closed as per https://contributors.scala-lang.org/t/2-13-0-m5-release-train/2125/39 ?

[dwijnand]

I think while:

• scala 2.13.0-M5 support #26043 is still unmerged (the publishings were off of that, also it needs a rebase), and
• not all modules of Akka were published afaik

maybe we should, calling this "effectively done" and create follow-up tickets for the follow-up work, that interest parties can subscribe to if interested. For instance, I'd be interested in tracking when 2.13 support is entirely merged into the master build/CI and by default a part of Akka releases, rather than in opt-in/"someone do it" state.

[dwijnand]

Well, #26043 is merged now.

@raboof WDYT about closing this and opening another issue detailing any and all follow-up work?