[3.3.x]: Scala 2.13.0-RC2 - #2031
Conversation
…created before attempting to use admin_drop_schema
…enerate unique table names in tests
|
/cc @SethTisue. :-) |
|
|
||
| def +=(s: String): SQLBuilder | ||
|
|
||
| def sep[T](sequence: scala.collection.immutable.Iterable[T], separator: String)(f: T => Unit): Unit = { |
There was a problem hiding this comment.
In the current master branch we use Iterable which expands to scala.collection.Iterable
Is there any reason to choose for the immutable variant specifically?
If we do chose for scala.collection.Iterable for 2.13 then for binary compatibility we can use the deprecated Traversable type alias, see https://github.com/scala/scala/blob/2.13.x/src/library/scala/package.scala#L51
There was a problem hiding this comment.
In the current master branch we use
Iterablewhich expands toscala.collection.Iterable
Is there any reason to choose for the immutable variant specifically?
No reason. Let's stick with scala.collection.Iterable.
If we do chose for
scala.collection.Iterablefor 2.13 then for binary compatibility we can use the deprecatedTraversabletype alias, see https://github.com/scala/scala/blob/2.13.x/src/library/scala/package.scala#L51
I suggest then to forward port some of the changes here with deprecation notice, and not deprecate in a patch version of 3.3.x where Scala 2.12 is fully supported and there is no reason to deprecate methods using Traversable.
WDYT?
There was a problem hiding this comment.
Remember that 3.3.x must be binary compatible with 3.3.0 for scala 2.12 and 2.11.
There was a problem hiding this comment.
I suggest then to forward port some of the changes here with deprecation notice, and not deprecate in a patch version of 3.3.x where Scala 2.12 is fully supported and there is no reason to deprecate methods using Traversable.
Do you mean the changes where Traversable(Once) is replaced by Iterable(Once)?
If using separate source files for pre- and post 2.13 can be avoided when we definately should. For this PR where we must maintain binary compatibility we can use Traversable and TraversableOnce. In scala 2.13 these are aliases for Iterable and IterableOnce.
To some extent I agree with the point that the type change from Traversable to Iterable might require deprecation warnings. However since nearly all Traverable subtypes are also Iterable, it probably won't cause any source-compatibility problems in practise, and if so these problems should not be hard to fix
There was a problem hiding this comment.
Remember that 3.3.x must be binary compatible with 3.3.0 for scala 2.12 and 2.11.
Yep, this is what I'm trying to do in this PR. So far, it looks like MiMa checks are happy with the changes here. :-)
Do you mean the changes where Traversable(Once) is replaced by Iterable(Once)?
I mean, for the 3.3.x branch, have both supported and avoid deprecating the methods using Traversable since this type is not deprecated in Scala 2.12/2.11. For master, we can have overloads to support both and deprecate the version using Traversable. But I don't have a strong opinion here, and we can go for Iterable without deprecating as you said.
Anyway, it is out of the scope for this PR, I think. Here my only objective is to have 3.3.x artifacts for Scala 2.13.
There was a problem hiding this comment.
I agree that the deprecation is out of scope for this PR.
However the original point I was trying to make was that we can use the same code for all scala versions. In that case we should use the Traversable/TraversableOnce type.
In scala 2.13 Traversable is a type alias for Iterable.
Not having to maintain separate sources for the different scala versions keeps the build as simple as possible.
There was a problem hiding this comment.
@WellingR, got it. Sounds like a good plan to me.
|
@WellingR, see the new commits based on your review. Thanks! |
|
Depends on #2040. |
* Scala 2.13.0-RC2 * Update scalatest version in samples
|
Ok, I'm planning to merge this one and cut 3.3.1-RC1 with support for Scala 2.13.0-RC2. I will do it later tonight unless someone blocks me! :-) |
Backports #2023, #2018 and #2012 to branch 3.3.x.
So that we avoid breaking binary compatibility and ensures that other projects using Slick can also cross-build using Scala 2.13.0 doing a patch upgrade.
Status
WIP since this is still using scala-collections-compat 1.0.0, but stable libraries should instead use 2.0.0. See note here: https://github.com/scala/scala-collection-compat#compatibility-library