is there a standard/recommended way to back-publish?

[SethTisue]

e.g. suppose I already published for JVM and Native and Scala.js 1.0.0-RC2, but now I want to publish the same version again but for Scala.js 1.0.0 final only

@olafurpg how do you suggest that people do this? tag and push a commit that removes the release combinations you don't want?

[olafurpg]

It's a good question 🤔 I would recommend publishing manually from your computer in this case.

You might be able to hack it by pushing a commit that does some modifications to the build

• hardcode the version number with version in ThisBuild ~= (_ => "NEW_VERSION")
• disable publishing in unwanted combinations with skip in publish := true

We might still need to make some changes in sbt-ci-release to detect this case because the plugin assumes there must be a git tag push in order to do a stable release https://github.com/olafurpg/sbt-ci-release/blob/5f0ca4509f4f0161168220cec7776df592daf7dd/plugin/src/main/scala/com/geirsson/CiReleasePlugin.scala#L33

[eed3si9n]

I would recommend publishing manually from your computer in this case.

Not sure if this would work for the modules maintained by Scala team + contributors since we normally limit the people who has Sonatype credentials, and we also want to give maintainers with repo push rights to be able to back publish artifacts.

I wonder if we can encode subproject name and optional Scala version name into the tag as follows:

v$version(#($scalaVersion)#$subproject)

examples

• v1.0.0 means all subprojects, all Scala versions +publishSigned
• v1.0.0#2.13.1 means all subprojects, only Scala 2.13.1 ++2.13.1 publishSigned
• v1.0.0##fooJS means only fooJS, all Scala versions +fooJS/publishSigned
• v1.0.0#2.13.1#fooJS means only fooJS on Scala 2.13.1 ++2.13.1 fooJS/publishSigned

[olafurpg]

@eed3si9n You could push a tag for a commit that

• sets the CI_RELEASE environment variable (which defaults to +publishSigned) in the YAML config
• hardcodes the version number in build.sbt

This plugin doesn't so much except delegate to other plugins like sbt-dynver (to set the version) and sbt-sonatype (to publish). I'm not sure how much we can do to solve this problem generically.

[olafurpg]

Alternatively, in a lot of projects I suspect it's OK to publish a new version with the entire new cross build.

[lrytz]

I wonder if we can encode subproject name and optional Scala version name into the tag as follows:

v$version(#($scalaVersion)#$subproject)

I sort of did this for our modules (https://github.com/scala/scala-parser-combinators/blob/d2e6685145ca4a9298c3d2ac0bde5ccf090f5d99/build.sh#L13-L15) but you still end up running in limitations.

I think the best solution is to push a new commit that modifies the .travis.yml to do the version numbers, and create a new tag with some random #suffix that is simply dropped (https://github.com/scala/sbt-scala-module/blob/39a3019e7c68b5d98af665a8c9254348b402ac51/src/main/scala/ScalaModulePlugin.scala#L33-L36)

[SethTisue]

@dwijnand is ignoring #suffix something that sbt-dynver ought to do, do you think? perhaps that's all that's needed here (plus a little documentation)

[dwijnand]

I think there's no basis for dynver to be doing that out the box.

It's really trivial to post-process the version string: https://github.com/dwijnand/sbt-dynver#custom-version-string

Personally I would look to moving to a git-ops like setup here, for back-publishing versions, instead of trying to codifying this with some crazy string pattern.

[SethTisue]

Personally I would look to moving to a git-ops like setup here

sorry, no idea what that means

[dwijnand]

I couldn't find a good reference, but my understanding of the basic premise is you encode in a git repo the state you want the world and have an operator execute it.

So here you'd PR a descriptor file which describes what to release and CI would make it so.

[eed3si9n]

https://www.weave.works/blog/gitops-operations-by-pull-request

In Kubernetes deployment, instead of using command line to manually deploy things, GitOps tells you to put all the configurations into another repo, and send a pull request to it instead (Upon merge, a robot does the configuration change).

[olafurpg]

Gonna close this as won't fix. My recommendation would be to manually back-publish in case releasing a new version is not an option. In my projects, I always publish a new version because it's quite common that the master branch includes 1-2 commits that affect semantics anyways.

[SethTisue]

Here's an example of someone doing back-publishing via a custom GitHub Actions workflow (rather than falling back to using their own laptop): typelevel/kind-projector#206

[tgodzik]

We also actually did that recently to not need to release full Metals release 😅

https://github.com/scalameta/metals/pull/3557/files