Consider removing sbt-release-early about laserdisc HOT 6 CLOSED

This should be related to the way sbt-sonatype handles repositories xerial/sbt-sonatype#49
I’m all for replacing it but I wonder if the problem is not on having the scalaVersion matrix in travis

from laserdisc.

I wonder if you should use mill 😆
It does actually have some interesting selling points (as pointed out in the linked discussion).

from laserdisc.

it's worth a try. I can pick this up as soon as I have fixed the client.

from laserdisc.

I went a bit ahead (given the joy of using sbt-ci-release on Eisner) and I've created a fresh GPG key for this, I pushed it to a keyserver and have already added all Travis env variables (w/o removing anything still needed by sbt-release-early)..

To get this completed, sbt-ci-release needs now still:

• some work on build.sbt and project/plugins.sbt as per https://github.com/olafurpg/sbt-ci-release#sbt
• some .travis.yml TLC as per https://github.com/olafurpg/sbt-ci-release#travisyml (see example here

With the above (ideally making sure last stage does not recompile...) I think we're probably good to go w.r.t. this

from laserdisc.

For the last couple of releases I set the max concurrent jobs to 1 on Travis and they went fine. This proves the problem is the releases being executed in parallel as @sirocchj suggests. The drawback of the workaround, though, is that now a full release takes double the time (around 50 minutes at the moment).

from laserdisc.

@barambani should we https://github.com/olafurpg/sbt-ci-release ?

from laserdisc.