Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
SethTisue opened this issue Feb 15, 2020 · 14 comments · Fixed by #322
Closed

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

SethTisue opened this issue Feb 15, 2020 · 14 comments · Fixed by #322

Comments

@SethTisue
Copy link
Member

SethTisue commented Feb 15, 2020

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
Copy link
Member

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
Copy link
Member

eed3si9n commented Feb 15, 2020

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
Copy link
Member

@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
Copy link
Member

olafurpg commented Feb 15, 2020

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

@lrytz
Copy link
Contributor

lrytz commented Feb 17, 2020

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
Copy link
Member Author

@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
Copy link
Member

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
Copy link
Member Author

SethTisue commented Feb 19, 2020

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

sorry, no idea what that means

@dwijnand
Copy link
Member

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
Copy link
Member

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
Copy link
Member

olafurpg commented Nov 3, 2020

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
Copy link
Member Author

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
Copy link
Contributor

tgodzik commented Jan 24, 2022

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

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

@eed3si9n
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants