Thank you!
Thank you, Frank. (And also, we can never thank you and your contributors too many times for Scala Steward, which is immensely valuable.)
Thank you, Seth!
@fthomas, I need to mention that Scala Steward is one of the best things in the Scala Ecosystem.
We were discussing how to best align Scala Steward with Scala 3 releases and we wonder if it would be possible if Scala Steward has some kind of trigger mechanism (e.g. similar to what GithubAction has) so then once release notes (and we) are ready we can manually ask Scala Steward to update the ecosystem.
Of course, we are open to other options (like Metadata in .pom files).
Thank you!
The mention of manually asking Scala Steward to start creating PRs got me thinking. Scala Steward supports repo-specific config files that can be used to ignore, pin, or allow only certain updates. It also supports a default repo config which can be set per Scala Steward installation and is merged with the repo-specific configs. I’ve used this default repo config for example for ignoring Scala 2 updates as mentioned in Coordinate compiler and tooling releases? - #40 by fthomas. If we would extend Scala Steward to also read a global config that lives in the Scala Steward GitHub repo, it could be used to manually trigger new Scala (or any other library) updates. It would work like this: Scala 2/3 artifacts are added once to the updates.ignore
list with next unreleased version (for example 3.1.1). Every Scala Steward installation will now ignore updates to this version and not create PRs. Once 3.1.1 is released and announced, the Scala 3 team makes a PR to the global Scala Steward config and sets the ignored version to 3.1.2. All (public and private) Scala Steward installations will then start creating updates to 3.1.1. Once 3.1.2 is announced, the ignored version is again bumped to the next unreleased version. And so on and so forth.
This solution has the advantage that it could implemented easily with only a few modifications to Scala Steward. @SethTisue and @romanowski, would this work for the Scala 2 and Scala 3 teams?
Sounds good to me. I don’t mind a few extra manual steps.
Here is how that would look like in practice: Support reading a default repo config from this repository by fthomas · Pull Request #2337 · scala-steward-org/scala-steward · GitHub
Just to be aware, I am running scala-steward on an own gitlab instance. The approach will also work for me as I am merging upstream first (for each run) before running the analysis. It should be well documented so that others running scala-steward on their own do not suddenly not get any scala upates any more, i.e. they need to merge upstream as well regularly
They do not need to merge upstream regularly because Scala Steward will load the default repo config from the main branch from the scala-steward GitHub repository at start-up. So if Scala maintainers update the default repo config via a PR, the changes will be immediately visible to all Scala Steward installations on their next run.
The PR that implements this change is here: https://github.com/scala-steward-org/scala-steward/pull/2337
Ah sweet, even better
Yes, that is precisely what we need for Scala 3 releases, thank you!
We are already doing several automated PRs during the release of a new version of the Scala 3 compiler (example). Adding another one won’t be a problem.
#2337 has been merged now and allows maintainers to tell Scala Steward to ignore updates until the new version is announced. I hope this improves the experience with Scala Steward and future Scala releases!
P.S.: If other maintainers need help adding their artifacts to https://github.com/scala-steward-org/scala-steward/blob/master/modules/core/src/main/resources/default.scala-steward.conf, feel free to ping me.
It’s not just that scalasteward is among the best things in the scala ecosystem, Frank is one of the nicest people who gets stuff done.
Thank you for scala Steward and thank you for being nice.
Thank you, that is a very kind of you! This is a good opportunity to mention that until now over 80 people (wow!) have contributed to Scala Steward for which I’m immensely grateful.
PR with extensive changes to our release steps, based on all of the feedback above: edits to Scala release steps by SethTisue · Pull Request #804 · scala/scala-dev · GitHub
(And this is just in time for 2.13.8 which we hope to release on Monday. We can keep making adjustments for subsequent releases, of course.)