Move build matrix to .travis.yml and reinstate scala-native support

[gourlaysama]

1. Move build matrix to .travis.yml: no more ScalaVersionByJvm.

This does the same thing as scala/scala-xml#223 but for parser-combinators:

• the matrix build is moved to .travis.yml, with
  • jdk 6, 8 and 11
  • scala 2.11.12, 2.12.7 and 2.13.0-M5
  • JVM, JS 0.6.25 (and JS 1.0.0-M5 eventually)
  • a few combinations are disabled when not supported or superfluous
• re-publishing is done by adding a commit above a tag with the version
  change and pushing a new tag
• ScalaVersionByJvm is not used, crossScalaVersion is enough

---

2. And with that we can reinstate support for scala native:

It was reverted in #135 because of build problems, but this is very easy
to add now: we add a single 'jdk8 + scala 2.11.12' job to the build
matrix, and also restrict publishing to those versions to be sure.

Locally, the native subproject can be run with any jdk > 6 and works
normally.

fixes #141.

[ashawley]

We have been using this in scala-xml. There was something nice about scalaVersionByJvm in that it allows Travis to still build and test across a lot of settings, but only publish to sonatype for specific explicit combinations. Buyer beware: Publishing across all Travis builds produces a bunch of artifacts in sonatype. Apparently, this situation makes it difficult to select and publish the desired artifacts.

[gourlaysama]

There was something nice about scalaVersionByJvm in that it allows Travis to still build and test across a lot of settings, but only publish to sonatype for specific explicit combinations.

Isn't that what RELEASE_COMBO is for? The way I understand it, publish-signed will only be called when it is set to true, so only for combinations we actually want to publish.

[ashawley]

You're right I mischaracterized it. The release-combo does help with the Java and Scala version combination, I guess the problem is that we have js and native targets (well, scala-xml doesn't have native, but I guess you do).

[gourlaysama]

In this case it should work out. RELEASE_COMBO will be set 7 times (out of 9 builds): 3 JVM builds, 3 JS (on the same JDKxScala combo) and the one native build.

What I liked about scalaVersionsByJvm was that it was very readable, including the publishing part, and all in the same place.

[gourlaysama]

Another idea I had was to remove the RELEASE_COMBO detection in build.sh and not rely on travis to build the matrix, but manually list what we want, including publishing:

matrix:
  include:
    - jdk: openjdk6
      scala: 2.11.12
      env: RELEASE_COMBO=true
    - jdk: openjdk6
      scala: 2.11.12
      env: SCALAJS_VERSION=0.6.25 RELEASE_COMBO=true
    - jdk: oraclejdk8
      scala: 2.12.7
      env: RELEASE_COMBO=true
    - jdk: oraclejdk8
      scala: 2.12.7
      env: SCALAJS_VERSION=0.6.25 RELEASE_COMBO=true
    - jdk: oraclejdk8
      scala: 2.13.0-m5
      env: RELEASE_COMBO=true
    - jdk: oraclejdk8
      scala: 2.13.0-m5
      env: SCALAJS_VERSION=0.6.25 RELEASE_COMBO=true
    - jdk: openjdk11
      scala: 2.12.7
    - jdk: openjdk11
      scala: 2.13.0-M5
    - jdk: orablejdk8
      scala: 2.11.12
      env: SCALANATIVE_VERSION=0.3.8 RELEASE_COMBO=true

It's tedious, but all the versions, and whether to publish, are all neatly listed in the same place.

[ashawley]

I also liked the readability of the sbt magic. It's much better than a wall of shell scripting and YAML. I was sorry to see it go.

[SethTisue]

perhaps not the last word on this, but let's try it this way for a while...