Please add support to Scala 2.13.16 and make new release

[bartoszkosiorek]

Please add support for Scala 2.13.16:
https://github.com/scala/scala/releases/tag/v2.13.16

Finally it would be great to release new version as for example scala 2.13.15 is supported only on master (not with latest release v6.6.0)

[bartoszkosiorek]

@WojciechMazur Do you think you could take a look at this implementation if it is correct?

[WojciechMazur]

I can help with upgrade (although you've opended the PR already so there wouldn't more to do probably) but I would not be able to make a release.

@liucijus @simuons
Is there some plan for releases? Is it blocked by something, eg. ongoing work by @mbland?
Should users use a fixed commit version? I guess there was a lot of changes since the last release half year ago.

[mbland]

The 2.13.16 update could go in before the Bzlmod changes from #1482. There could even be a point release before that; everything I've done so far maintains compatibility with Bazel 6.5.0 and 7.5.0. (Maybe earlier versions of each, too, but if not, I think the burden should be on users to bump their minor versions of Bazel.)

That PR isn't quite ready yet, though. I'll comment on it. Actually, I just updated scripts/create_repository.py locally, and did get almost the same result. Commenting now...

[mbland]

BTW, the final Bzlmod changes are imminent. Just to be clear, we don't have to wait for them to land and to cut the next major release before cutting another minor release, but the wait might not be very long, either. It's all up to whatever @simuons and @liucijus prefer.

[crt-31]

I guess there was a lot of changes since the last release half year ago.

I vote that we should definately have a 6.x release before integrating the bzlmod. I want some of the changes since July.

[mbland]

It just occurred to me that I spoke a little too soon. There are some breaking changes in master, described in #1482 (comment).

They're mostly very easy to resolve, but they are breaking. So the next release should be a major one either way. It would be possible to release 7.0 without Bzlmod, and 7.1 with.

It would make sense to merge #1696, #1698, and #1700 one way or another. After that, the change to introduce Bzlmod with be one small-ish commit (modulo all the new MODULE.bazel and empty WORKSPACE.bzlmod files, which mirror existing WORKSPACE configs). Then after that, the change to introduce Bazel 8 compatibility (which, for Bazel 6, requires compiler flags for WORKSPACE and breaks Bzlmod completely) will be small-ish as well. So it's a choice between three releases in a relatively short succession (7.0 without bzlmod, 7.1 with, 8.0 with Bazel 8), or two (7.0 with bzlmod, 8.0 with Bazel 8).