Good idea! The URL pattern could then be something like https://www.scala-lang.org/news/$version
.
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)
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.
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
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.
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).
@fthomas, I need to mention that Scala Steward is one of the best things in the Scala Ecosystem.
Thank you!
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.
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.
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).
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
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?
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.