Update munit to 1.0.0-RC1 in series/0.23

[http4s-steward]

About this PR

📦 Updates org.scalameta:munit from 1.0.0-M11 to 1.0.0-RC1

📜 GitHub Release Notes - Version Diff

Usage

✅ Please merge!

I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.

If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.

Configure Scala Steward for your repository with a .scala-steward.conf file.

Have a fantastic day writing Scala!

🔍 Files still referring to the old version number

The following files still refer to the old version number (1.0.0-M11).
You might want to review and update them manually.

docs/changelog.md

⚙ Adjust future updates

Add this to your .scala-steward.conf file to ignore future updates of this dependency:

updates.ignore = [ { groupId = "org.scalameta", artifactId = "munit" } ]

Or, add this to slow down future updates of this dependency:

dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.scalameta", artifactId = "munit" }
}]

^{labels: library-update, early-semver-pre-release, semver-spec-pre-release, old-version-remains, commit-count:1}

[rossabaker]

I'm not sure what to do with this one, since we accidentally exposed it via laws.

[rossabaker]

@valencik Do you have opinions on how to proceed here?

[valencik]

Hey, I wanna check that I understand things.
Based on #6657 and #6739, it looks like our laws depend on munit?
And that dependency comes about via LawAdapter depending on munit.CatsEffectAssertions which comes from munit-cats-effect which of course depends on munit. Is that right?

I guess I am unsure of the implications.
(in general, I'm pretty new to binary compatibility concerns 😬)

I don't know if this helps, but we could also wait until munit 1.0.0 final, which shouldn't be too long from now (it was recently decided to not block on some other things, so it should be coming out within a week or two unless problems are found in the RC1).

[rossabaker]

That trace sounds right. And it's a problem because:

1. It looks like it's a binary-breaking change in the dependency, because deprecated methods were removed.
2. Even if it weren't binary breaking, SBT is going to think it was binary breaking, because an RC isn't inferred to be binary compatible with anything else.

I don't think hardly anyone external is using the laws. We can probably just sit on this until final.

[valencik]

Thanks, that clears things up. Unfortunate we're in this situation.

I agree we can probably wait for munit 1.0.0 final.
We'll definitely want to call this out in the release notes.