release 2.1.3

[SethTisue]

for two reasons:

• we should (as @ekrich has pointed out) publish for Scala.js 1.0.0-RC1
• to address Missing 2.1.2 release of scala-collection-migrations on Mavenrepository #245 (scala-collection-migrations didn't publish successfully when we did 2.1.2)

this will be the first time we release this module with sbt-ci-release instead of the old module releasing process, so I'm half expecting it will go wrong. and there are some ways in which it might go wrong that would still involve scala-steward jumping on it before you can say "holy runaway automation, Batman"

so I'd like to do a 2.1.3-RC1 first, see if everything publishes, and have Eric verify that the artifacts are usable with Scala.js 1.0.0-RC1. if that all goes well, I'll follow up with a proper 2.1.3 release

(2.1.2 release ticket was #214)

[SethTisue]

this will be the first time we release this module with sbt-ci-release instead of the old module releasing process, so I'm half expecting it will go wrong

though I see now that @lrytz already did a v2.1.3-TEST (commit: 4bb98e7) at https://travis-ci.org/scala/scala-collection-compat/builds/585968641 (history at #252, #255). that's encouraging. regardless, I would like to do an RC, especially since it's my first time doing a module release with the new process

[SethTisue]

• tag: https://github.com/scala/scala-collection-compat/releases/tag/v2.1.3-RC1
• release build: https://travis-ci.org/scala/scala-collection-compat/builds/623505472

gah [error] java.io.FileNotFoundException: /home/travis/.sbt/gpg/secring.asc (No such file or directory)

is it sbt/sbt-ci-release#64 ?

we see at 600dba3 that Lukas believed the problem to be fixed as of sbt-scala-module 2.1.2

[SethTisue]

my bedtime is approaching. @lrytz perhaps you could take a look if you're not too busy, since you've been over this ground before. otherwise I'll come back to it myself (I am no longer underwater, I have a decent amount of time this week and next)

[lrytz]

Hmm :-(

Comparing to the test release, sbt was upgraded from 1.3.0 to 1.3.4. Maybe that broke the workaround sbt/sbt-ci-release#66?

I'll do some testing with https://github.com/lrytz/travis-test.

[lrytz]

Ah, also in the travis log:

The good version has:

Running CI: 
compat211/clean
compat211/test
compat211/publishLocal
set pgpSecretRing := pgpSecretRing.value
set pgpPublicRing := pgpPublicRing.value
compat211/publishSigned
sonatypePrepare
sonatypeBundleUpload
sonatypeClose

The bad one:

Running CI: 
compat211/clean
compat211/test
compat211/publishLocal
compat211/publishSigned
sonatypePrepare
sonatypeBundleUpload
sonatypeClose

So it's indeed the workaround that's missing.

[lrytz]

travis-test worked. but i just saw now that this repository doesn't use the ci-release task, but replicates its implementation to some degree (https://github.com/scala/scala-collection-compat/blob/master/build.sbt#L348-L359). So the workaround removed in 600dba3#diff-fdc3abdfd754eeb24090dbd90aeec2ce actually needs to stay. It seems I never tested it after removing it... Sorry!

[lrytz]

Tagged an v2.1.3-RC2, and the builds look fine: https://travis-ci.org/scala/scala-collection-compat/builds/623598336

I left the staging repos in place, here's a screenshot:

[ekrich]

@lrytz I just wanted to let you know that the Travis file looks super good. I wish somehow we could use a Travis file like that with sbt-ci-release out of the box but sbt-ci-release uses Travis Stages in its example.

This is my solution using Stages - https://github.com/ekrich/sconfig/blob/topic/sjs10rc1/.travis.yml
As you can see, it is not elegant.

If we could figure out how to use sbt-ci-release with a Travis file like yours in an idiomatic way without the extra code in the sbt file we could make everyone's life easier.

This would make a formula that anyone could copy and tweak and make this publishing easy and fast. cc/ @SethTisue

Even @tpolecat would be happy.

[lrytz]

@ekrich the build.sbt file in this repo is rather complicated for reasons I'm not aware. I just did the minimal change to get ci-release working with it the way I want.

In other modules, we use a pretty standard build.sbt and travis.yml, and the build script actually invokes sbt ci-release. See https://github.com/scala/scala-collection-contrib for example. We're not using build stages.

Is this what you're looking for?

[ekrich]

@lrytz I am not looking particularly but this was something discussed on different chats about how hard publishing is to do. sbt-ci-release really helps but doing a matrix with stages in Travis is unclear to me and it seems that many projects have glue in the sbt or a build.sh or the like. I am referring to sbt-ci-release which is a godsend to many of us - https://github.com/olafurpg/sbt-ci-release

[SethTisue]

I just hit "release" on the staging repos, so the 2.1.3-RC2 artifacts should reach Maven Central before long. @ekrich please let us know whether the Scala.js 1.0.0-RC1 artifacts work for you

[SethTisue]

(before doing 2.1.3 final we'll also want to make sure that artifacts show up at https://repo1.maven.org/maven2/org/scala-lang/modules/scala-collection-migrations_2.12/2.1.3/)

[SethTisue]

(before doing 2.1.3 final we'll also want to make sure that artifacts show up at https://repo1.maven.org/maven2/org/scala-lang/modules/scala-collection-migrations_2.12/)

they didn't. pursuing that at #279