Publish snapshots by default and add an override for hash releases

[vasilmkd]

@armanbilge and I worked on this after discussing SNAPSHOT releases with other maintainers on Discord. We think this is generally desired by people.

By combining both the hash and the -SNAPSHOT suffix, we believe we can achieve a sensible middle ground where snapshots are mutable but not actually mutated (unless the user goes out of their way to make sure the hash matches a previous version), so this helps with the stability, maven central is not polluted (this doesn't at all affect tagged releases and they can still be done manually) and maintainers have a steady stream of stable snapshots to test stuff and look for regressions.

[vasilmkd]

From sbt-sonatype:

    sonatypeBundleDirectory := {
      (ThisBuild / baseDirectory).value / "target" / "sonatype-staging" / s"${(ThisBuild / version).value}"
    },

and the error is the following:

java.io.IOException: Supplied file /Users/vasil/Code/sbt-spiewak/target/sonatype-staging/0.23-11-4c9ab83-SNAPSHOT is a not an existing directory!
        at org.sonatype.spice.zapper.fs.AbstractDirectory.<init>(AbstractDirectory.java:32)
        at org.sonatype.spice.zapper.fs.DirectoryIOSource.<init>(DirectoryIOSource.java:68)
        at org.sonatype.spice.zapper.fs.DirectoryIOSource.<init>(DirectoryIOSource.java:59)
        at org.sonatype.spice.zapper.fs.DirectoryIOSource.<init>(DirectoryIOSource.java:50)
        at xerial.sbt.sonatype.SonatypeClient.$anonfun$uploadBundle$2(SonatypeClient.scala:284)
        at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
        at scala.util.Try$.apply(Try.scala:213)
        at wvlet.airframe.control.Retry$RetryContext.runInternal(Retry.scala:268)
        at wvlet.airframe.control.Retry$RetryContext.run(Retry.scala:253)
        at xerial.sbt.sonatype.SonatypeClient.uploadBundle(SonatypeClient.scala:269)
        at xerial.sbt.sonatype.SonatypeService.uploadBundle(SonatypeService.scala:73)
        at xerial.sbt.Sonatype$.$anonfun$sonatypeBundleRelease$2(Sonatype.scala:181)
        at xerial.sbt.Sonatype$.withSonatypeService(Sonatype.scala:437)

version ends with a -SNAPSHOT, and the hash release doesn't.

[armanbilge]

Right, it seems like publishHash should drop -SNAPSHOT from the version number and proceed from there? IDK how easy that is...

[vasilmkd]

publishHash does drop it already. The problem is, this is not then communicated to sonatypeBundleRelease.

[armanbilge]

Ooh 😮

[vasilmkd]

The problem is that publish and releases "should be" separate steps.

[vasilmkd]

Here's a hash release:

addSbtPlugin("io.vasilev" % "sbt-spiewak-sonatype" % "0.23-12-4067672")

No snapshot resolver necessary.

[vasilmkd]

@armanbilge Can you try releasing a hash with this version too? The steps are sbt publishHasIfRelevant sonatypeBundleReleaseIfRelevant.

[armanbilge]

I've actually never released anything locally 😆 I'm not sure I know how.

[vasilmkd]

You need to have gpg set up. Don't bother if you haven't yet. I released the hash using the plugin, so it works.

[armanbilge]

What I can do easily, is toggle the setting so CI can release a stable hash instead. Would that be helpful?

[vasilmkd]

Actually yes, that's a good scenario to try. Thanks.

[vasilmkd]

What we should discuss again though is, should we flip everything, keep the old sbt-spiewak behavior exactly as it is, and instead add a publishSnapshot/releaseSnapshot that only releases a snapshot. We can still tweak the GHA yaml to cover that case.

[armanbilge]

I think that's a Daniel vs the world question 😅 IDK if anybody likes the current default.

[armanbilge]

What I can do easily, is toggle the setting so CI can release a stable hash instead. Would that be helpful?

Forgot to followup, this worked for me 👍