Move to Scala 2.13.0-M4

[lrytz]

Rebased the newCollectionsRebase branch on current master. This can go in now, no?

[ashawley]

Shouldn't this be marked private?

[lrytz]

yes good point. i did this only in #223, sorry for the confusion

[ashawley]

So we made these traits private. This means people can't use it as a trait. However, the traits are published, and they are revealed in the type signatures.

 :type -v <x y="z"/>.attributes
// Type signature
scala.xml.MetaData

// Internal Type structure
TypeRef(
  TypeSymbol(
    abstract class MetaData extends AbstractIterable[scala.xml.MetaData] 
                   with Iterable[scala.xml.MetaData] 
                   with Equality 
                   with ScalaVersionSpecificIterableSerializable[scala.xml.MetaData] 
                   with Serializable

  )
)

Cost of doing business or should we do something else?

[ashawley]

Fortunately, dropping such a trait from a future version will be caught by Mima:

> xml/mimaReportBinaryIssues
[info] scala-xml: found 13 potential binary incompatibilities while checking 
[info] against org.scala-lang.modules:scala-xml_2.13.0-M5:1.1.1
...
[error]  * the type hierarchy of class scala.xml.NodeSeq is different in 
[error]  current version. Missing types {scala.xml.ScalaVersionSpecificIterableSerializable}
[error]    filter with: ProblemFilters.exclude[MissingTypesProblem]("scala.xml.NodeSeq")

[ashawley]

This can go in now, no?

My effort to keep your branch up-to-date was in no way a tacit approval of the changes it contained.

Like most Scala programmers, I am generally confused about the 2.13 changes, so I have a lot of questions. Since this is my first opportunity to review the changes here, I guess the first practical question I have is: "If we merge this, can we still make a 1.1.1 release from master? Can we trust MiMa here?"

[lrytz]

Can we trust MiMa here?

Very good question. I'll look in more detail next week.

[lrytz]

I looked at the change again in detail with the goal to find binary incmopatible changes. I'm confident that this PR doesn't break binary compatibility.

• NodeBuffer extends a new trait ScalaVersionSpecificNodeBuffer. This is backwards compatbile (https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.4.4).
  • The change is not forwards compatbile, i.e., a file compiled against the new version might have a reference to the new interface ScalaVersionSpecificNodeBuffer and therefore not work with the old library. But AFAIK we don't guarantee forwards binary compatibility for modules (unlike the standard library).
  • The stringPrefix method is now inherited from ScalaVersionSpecificNodeBuffer. This is binary compatible. In 2.11, the compiler synthesizes a method in the class NodeBuffer that forwards to the implementaion, so the class has exactly the same method. In 2.12, the compiler in fact does the same, even though it could avoid it (the method is a "default" method in ScalaVersionSpecificNodeBuffer). Either way, both 2.12 cases are binary compatible, existing invocations of the method continue to work.
• For NodeSeq the situation is the same, there is a new parent ScalaVersionSpecificNodeSeq implementing the method newBuilder.

I did a few tests with scala-xml 1.1.0 and a local version published from this PR, both with 2.11 and 2.12.

[lrytz]

Rebased this PR on top of #223 (to avoid future conflicts).

[ashawley]

Needs rebase after merge of #223?

[lrytz]

Done!

[ashawley]

I'm confident that this PR doesn't break binary compatibility.

Thanks for this analysis.

So presumably a user who was cross-compiling with 2.13.0-M3 and 1.1.0 would still be able to cross-compile with a 1.1.1 release and 2.13.0-M4? Maybe not if the underlying collection calls were changed out from under them?

[ashawley]

So presumably a user who was cross-compiling with 2.13.0-M3 and 1.1.0

Or... when 2.13.0 finally drops, they technically lose source compatibility with scala-xml 1.1.0.

[lrytz]

1.1.1 on 2.12 has the same API as 1.1.0 on 2.12. Changes are only required if a project needs to cross-compile with 2.13.

For most users of scala-xml, it is possible to adapt the code to cross-compile between 2.12 and 2.13. A goal of the collections redesign is that user code can cross-compile.

But yes, NodeSeq is different on 2.13 because Seq[Node] is different. So scala-xml 1.1.1 on 2.12 doesn't have the same API as scala-xml 1.1.1 on 2.13.

See https://github.com/scala/scala/releases/tag/v2.13.0-M4 and https://github.com/scala/collection-strawman/wiki/FAQ for details (end-user documentation is coming for the final release).

[SethTisue]

@ashawley do you have any remaining concerns about this...?

[ashawley]

No, I have no remaining concerns. Will be releasing 1.1.1 relatively soon, and will probably work on getting these changes merged after that.

[SethTisue]

Scala 2.13.0-M5 is now out

[SethTisue]

there are some M5 commits at https://github.com/scalacommunitybuild/scala-xml/commits/community-build-2.13

[ashawley]

Thanks, Seth.

Working on updating newCollectionsBootstrap, then we can tag and publish something for M5.

Test build here: https://travis-ci.org/ashawley/scala-xml/jobs/422693328

Only the M5 builds will succeed. Fortunately, the build is separated out, so I think publishing will work when we tag.

[seratch]

Any updates on this?

[SethTisue]

@seratch see #256

[ashawley]

Changes for 2.13.0-M5 will continue in to #260.