Coordinate compiler and tooling releases?

Good idea! The URL pattern could then be something like https://www.scala-lang.org/news/$version.

3 Likes

By the way - I wholeheartedly agree! I’m an avid user of Scala Steward and I am immensely grateful to you and all contributors for it (alongside all your other contributions and libraries like refined)

4 Likes

For the record, I don’t think the POM idea is fatally flawed. But I should be more specific about why I’m also interested in discussing other options:

  • As a library maintainer, I can’t change my POM without publishing a new version
  • Publishing to Sonatype is a notoriously tricky and fragile process, and Sonatype is notoriously picky about the contents of POMs
  • It would be cool if there were a cultural norm in Maven land that POMs link to release notes, and if the Maven powers-that-be propagated some kind of standard for how to do it. But in practice, we’re not going to succeed in establishing that as a norm. In practice, only a relative handful of repos are going to actually do this, and the only reason they’re going to do it is to tell the steward what to do. It seems like unnecessary levels of indirection to me when I we could just be telling the steward directly.
3 Likes

Just checked if this would actually work. I pushed two tags to Tags · scala-steward-org/test-repo-2 · GitHub and created a release for v0.1 but not for v0.2. Unfortunately this does not make a difference for the status code of the release notes URLs:

$ curl --head -s -o /dev/null -w "%{http_code}\n" https://github.com/scala-steward-org/test-repo-2/releases/v0.1
200
$ curl --head -s -o /dev/null -w "%{http_code}\n" https://github.com/scala-steward-org/test-repo-2/releases/v0.2
200

So just tagging and not creating the release on GitHub does not make a difference with regards to the status code. It is only 404 if the tag does not exist:

$ curl --head -s -o /dev/null -w "%{http_code}\n" https://github.com/scala-steward-org/test-repo-2/releases/v0.3
404
1 Like

You can probably use the GitHub API v3 (non graphql) for that

Btw, I just configured my public Scala Steward instance to ignore all future Scala 2.x updates until it is able to wait for release announcements. @sjrd I hope this helps reducing the pressure to release matching Scala.js artifacts.

6 Likes

Thank you!

1 Like

Thank you, Frank. (And also, we can never thank you and your contributors too many times for Scala Steward, which is immensely valuable.)

8 Likes

Thank you, Seth! :heart:

@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).

3 Likes

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?

6 Likes

Sounds good to me. I don’t mind a few extra manual steps.

1 Like

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

1 Like

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

1 Like

Ah sweet, even better :+1:

2 Likes

Yes, that is precisely what we need for Scala 3 releases, thank you!

1 Like

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.

3 Likes

#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.

7 Likes

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.

7 Likes