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

[eed3si9n]

I have a PR for back publishing support - #322.

The current "bump the version" approach effectively pushes the work of figuring out the correct patch version number to the end users. In addition, if the plugin or the library does not cross publish all variants, then the end user might need to figure out different patch version to use the same code. For plugins like compiler plugins and sbt plugins (during 2.x milestones) I think this is a must-have feature.