cross-publish for sbt 2.0.0

[raboof]

Without actually switching to it for our build (that's #351)

Requires upstream:

• sbt-assembly
• https://github.com/jodersky/sbt-gpg/issues?q=is%3Aopen+is%3Aissue
• Add sbt 2.0 crossbuilds sbt/sbt-native-packager#1638

[BillyAutrey]

I started on sbt-ci-release. Because it pulls in plugins via addSbtPlugin, as far as I can tell we're forced to require crossbuilds of those plugins as well.

This means we'll need 2.0.0-M2 crossbuilds of:

• sbt-dynver
• sbt-git (in progress)
• sbt-pgp (done with 2.3.0)
• sbt-sonatype.

[BillyAutrey]

Side note - this plugin strips timestamps. But zinc removes them in 2.0.0, actually to try and create more reproducible builds.

I think some of this plugin's aims are still valuable to have separately (e.g., buildinfo for publication). But I wonder how much this will have to change for 2.0.0?

[raboof]

Side note - this plugin strips timestamps. But zinc removes them in 2.0.0, actually to try and create more reproducible builds.

I think some of this plugin's aims are still valuable to have separately (e.g., buildinfo for publication). But I wonder how much this will have to change for 2.0.0?

I agree! Making the stripping (or perhaps individual strippers?) optional is something I'd like to do in any case (#299), and under sbt 2.x could perhaps even become the default.

[raboof]

I started on sbt-ci-release. Because it pulls in plugins via addSbtPlugin, as far as I can tell we're forced to require crossbuilds of those plugins as well.

This means we'll need 2.0.0-M2 crossbuilds of:

• sbt-dynver
• sbt-git (in progress)
• sbt-pgp (done with 2.3.0)
• sbt-sonatype.

great that you're pushing for this! should we create a tracking issue in sbt-ci-release and link to that here?

[BillyAutrey]

great that you're pushing for this! should we create a tracking issue in sbt-ci-release and link to that here?

Sure, that's a good idea. I can do that.

[BillyAutrey]

sbt/sbt-ci-release#314