Please add support to Scala 2.13.16 and make new release #1699

bartoszkosiorek · 2025-02-14T09:55:09Z

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)

The text was updated successfully, but these errors were encountered:

Fixes: bazelbuild#1699

bartoszkosiorek · 2025-02-14T13:05:12Z

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

Fixes: bazelbuild#1699

WojciechMazur · 2025-02-14T13:35:43Z

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.

Fixes: bazelbuild#1699

mbland · 2025-02-14T15:57:07Z

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 · 2025-02-14T18:02:06Z

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 · 2025-02-14T18:23:24Z

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 · 2025-02-14T22:54:49Z

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

Fixes: bazelbuild#1699

bartoszkosiorek · 2025-02-15T09:58:59Z

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

Could you please add these information about breaking changes into rules_scala documentaion.
It would be great to have information how to upgrade to rules_scala 7.0 in official rules_scala documentation.

Describes the new `scala_toolchains()` API, breaking changes, Bazel compatibility matrix, and breaking of the `io_bazel_rules_scala` repo name dependency. Part of bazelbuild#1482, bazelbuild#1647, bazelbuild#1652, and bazelbuild#1699. Much of the README text regarding `WORKSPACE` configuration, Bazel compatibility, and breaking changes comes from: - bazelbuild#1482 (comment) Contains information about the upcoming Bzlmod implementation and Bazel 8 compatibility changes. With this information already in place, very little will need to change when these changes land. Those doc updates will land in the same commit as their respective implementations. Contains a light editing pass over almost every Markdown file to resolve `markdownlint` warnings when editing in VSCode. Also added `.markdownlint.json` to silence rule `MD033/no-inline-html`, since several docs contain `<br/>` and/or `<table>` elements. - https://github.com./DavidAnson/vscode-markdownlint?tab=readme-ov-file#markdownlintconfig Performed other opportunistic grammar edits and added new information, particularly to: - `docs/coverage.md`: Describes how to determine the default JaCoCo version used by `rules_java` - `scripts/README.md`: Updates `create_repository.py` docs extensively, and adds a section for `sync_bazelversion.sh`

Describes the new `scala_toolchains()` API, breaking changes, Bazel compatibility matrix, and breaking of the `io_bazel_rules_scala` repo name dependency. Part of bazelbuild#1482, bazelbuild#1647, bazelbuild#1652, and bazelbuild#1699, it also removes obsolete `WORKSPACE` APIs in favor of `scala_toolchains()`, et. al. Much of the README text regarding `WORKSPACE` configuration, Bazel compatibility, and breaking changes comes from: - bazelbuild#1482 (comment) The "Breaking changes in `rules_scala` 7.x" section of `README.md` describes the removed `WORKSPACE` macros, and provides guidance for adopting the `scala_toolchains()` API. Also includes information about the upcoming Bzlmod implementation (bazelbuild#1482) and the Bazel 8 compatibility changes for `rules_scala` 8.x (bazelbuild#1652). Contains a light editing pass over almost every Markdown file to resolve `markdownlint` warnings when editing in VSCode. Also added `.markdownlint.json` to silence rule `MD033/no-inline-html`, since several docs contain `<br/>` and/or `<table>` elements. - https://github.com./DavidAnson/vscode-markdownlint?tab=readme-ov-file#markdownlintconfig Performed other opportunistic grammar edits and added new information, including: - `docs/coverage.md`: Describes how to determine the default JaCoCo version used by `rules_java` - `scripts/README.md`: Updates `create_repository.py` docs extensively, and adds a section for `sync_bazelversion.sh` --- Since the next major release is imminent, ensuring the documentation accurately reflects all the changes since v6.6.0 has become an urgent priority. Rather than leave the old `WORKSPACE` APIs in place, which could lead to surprising failures, this change removes all of them. This also changes some code that still depended on some of these obsolete macros, including `scala_toolchains()`. Since all the toolchainization changes led to the entire project already using `scala_toolchains()` and `scala_register_toolchains()` exclusively, this proved a low risk refactoring. With some Bzlmod and Bazel 8 information already in place, very little will need to change when these implementations land. The commits that contain those implementations will also include their relevant documentation updates.

mbland · 2025-02-18T05:15:02Z

I've got a bzlmod-docs branch in my mbland/rules_scala fork with all the doc updates from #1482 (comment) and then some.

In the process, I realized it was best to remove all the old WORKSPACE APIs replaced by rules_scala_dependencies(), scala_toolchains(), and scala_register_toolchains(). I documented all the removals and how to upgrade.

I'm calling it a night for now. I want to get some testing in before I get a pull request out tomorrow. But I wanted to announce the branch so you know it's coming very soon.

Describes the new `scala_toolchains()` API, breaking changes, Bazel compatibility matrix, and breaking of the `io_bazel_rules_scala` repo name dependency. Part of bazelbuild#1482, bazelbuild#1647, bazelbuild#1652, and bazelbuild#1699, it also removes obsolete `WORKSPACE` APIs in favor of `scala_toolchains()`, et. al. Much of the README text regarding `WORKSPACE` configuration, Bazel compatibility, and breaking changes comes from: - bazelbuild#1482 (comment) The "Breaking changes in `rules_scala` 7.x" section of `README.md` describes the removed `WORKSPACE` macros, and provides guidance for adopting the `scala_toolchains()` API. Also includes information about the upcoming Bzlmod implementation (bazelbuild#1482) and the Bazel 8 compatibility changes for `rules_scala` 8.x (bazelbuild#1652). Contains a light editing pass over almost every Markdown file to resolve `markdownlint` warnings when editing in VSCode. Also added `.markdownlint.json` to silence rule `MD033/no-inline-html`, since several docs contain `<br/>` and/or `<table>` elements. - https://github.com./DavidAnson/vscode-markdownlint?tab=readme-ov-file#markdownlintconfig Performed other opportunistic grammar edits and added new information, including: - `docs/coverage.md`: Describes how to determine the default JaCoCo version used by `rules_java` - `scripts/README.md`: Updates `create_repository.py` docs extensively, and adds a section for `sync_bazelversion.sh` --- Since the next major release is imminent, ensuring the documentation accurately reflects all the changes since v6.6.0 has become an urgent priority. Rather than leave the old `WORKSPACE` APIs in place, which could lead to surprising failures, this change removes all of them. This also changes some code that still depended on some of these obsolete macros, including `scala_toolchains()`. Since all the toolchainization changes led to the entire project already using `scala_toolchains()` and `scala_register_toolchains()` exclusively, this proved a low risk refactoring. With some Bzlmod and Bazel 8 information already in place, very little will need to change when these implementations land. The commits that contain those implementations will also include their relevant documentation updates.

Describes the new `scala_toolchains()` API, breaking changes, Bazel compatibility matrix, and breaking of the `io_bazel_rules_scala` repo name dependency. Part of bazelbuild#1482, bazelbuild#1647, bazelbuild#1652, and bazelbuild#1699, it also removes obsolete `WORKSPACE` APIs in favor of `scala_toolchains()`, et. al. Much of the README text regarding `WORKSPACE` configuration, Bazel compatibility, and breaking changes comes from: - bazelbuild#1482 (comment) The "Breaking changes in `rules_scala` 7.x" section of `README.md` describes the removed `WORKSPACE` macros, and provides guidance for adopting the `scala_toolchains()` API. Also includes information about the upcoming Bzlmod implementation (bazelbuild#1482) and the Bazel 8 compatibility changes for `rules_scala` 8.x (bazelbuild#1652). Contains a light editing pass over almost every Markdown file to resolve `markdownlint` warnings when editing in VSCode. Also added `.markdownlint.json` to silence rule `MD033/no-inline-html`, since several docs contain `<br/>` and/or `<table>` elements. - https://github.com./DavidAnson/vscode-markdownlint?tab=readme-ov-file#markdownlintconfig Performed other opportunistic grammar edits and added new information, including: - `docs/coverage.md`: Describes how to determine the default JaCoCo version used by `rules_java` - `scripts/README.md`: Updates `create_repository.py` docs extensively, and adds a section for `sync_bazelversion.sh` - Replaces `starlark` code fences with `py`, since the syntax is identical and editors seem to support it better. --- Since the next major release is imminent, ensuring the documentation accurately reflects all the changes since v6.6.0 has become an urgent priority. Rather than leave the old `WORKSPACE` APIs in place, which could lead to surprising failures, this change removes all of them. This also changes some code that still depended on some of these obsolete macros, including `scala_toolchains()`. Since all the toolchainization changes led to the entire project already using `scala_toolchains()` and `scala_register_toolchains()` exclusively, this proved a low risk refactoring. With some Bzlmod and Bazel 8 information already in place, very little will need to change when these implementations land. The commits that contain those implementations will also include their relevant documentation updates.

mbland · 2025-02-18T14:55:47Z

Just posted #1703 with the doc changes and to remove the obsolete APIs.

mbland · 2025-02-20T17:46:15Z

I posted an update to #1482 describing the roadmap from here, including the possibility of releasing 7.0.0 with or without Bzlmod.

@bartoszkosiorek I'd appreciate any feedback on the README.md updates from #1703 if you have any (since you asked for it 😉).

Anyone else is welcome to comment on that pull request as well. It's probably easiest to select the "View file" option on the README.md changes to read the rendered doc instead of trying to parse all the diffs.

Fixes: #1699

Describes the new `scala_toolchains()` API, breaking changes, Bazel compatibility matrix, and breaking of the `io_bazel_rules_scala` repo name dependency. Part of bazelbuild#1482, bazelbuild#1647, bazelbuild#1652, and bazelbuild#1699, it also removes obsolete `WORKSPACE` APIs in favor of `scala_toolchains()`, et. al. Much of the README text regarding `WORKSPACE` configuration, Bazel compatibility, and breaking changes comes from: - bazelbuild#1482 (comment) The "Breaking changes in `rules_scala` 7.x" section of `README.md` describes the removed `WORKSPACE` macros, and provides guidance for adopting the `scala_toolchains()` API. Also includes information about the upcoming Bzlmod implementation (bazelbuild#1482) and the Bazel 8 compatibility changes for `rules_scala` 8.x (bazelbuild#1652). Contains a light editing pass over almost every Markdown file to resolve `markdownlint` warnings when editing in VSCode. Also added `.markdownlint.json` to silence rule `MD033/no-inline-html`, since several docs contain `<br/>` and/or `<table>` elements. - https://github.com./DavidAnson/vscode-markdownlint?tab=readme-ov-file#markdownlintconfig Performed other opportunistic grammar edits and added new information, including: - `docs/coverage.md`: Describes how to determine the default JaCoCo version used by `rules_java` - `scripts/README.md`: Updates `create_repository.py` docs extensively, and adds a section for `sync_bazelversion.sh` - Replaces `starlark` code fences with `py`, since the syntax is identical and editors seem to support it better. --- Since the next major release is imminent, ensuring the documentation accurately reflects all the changes since v6.6.0 has become an urgent priority. Rather than leave the old `WORKSPACE` APIs in place, which could lead to surprising failures, this change removes all of them. This also changes some code that still depended on some of these obsolete macros, including `scala_toolchains()`. Since all the toolchainization changes led to the entire project already using `scala_toolchains()` and `scala_register_toolchains()` exclusively, this proved a low risk refactoring. With some Bzlmod and Bazel 8 information already in place, very little will need to change when these implementations land. The commits that contain those implementations will also include their relevant documentation updates.

@bartoszkosiorek

* Update docs for version 7.0.0, remove old APIs Describes the new `scala_toolchains()` API, breaking changes, Bazel compatibility matrix, and breaking of the `io_bazel_rules_scala` repo name dependency. Part of #1482, #1647, #1652, and #1699, it also removes obsolete `WORKSPACE` APIs in favor of `scala_toolchains()`, et. al. Much of the README text regarding `WORKSPACE` configuration, Bazel compatibility, and breaking changes comes from: - #1482 (comment) The "Breaking changes in `rules_scala` 7.x" section of `README.md` describes the removed `WORKSPACE` macros, and provides guidance for adopting the `scala_toolchains()` API. Also includes information about the upcoming Bzlmod implementation (#1482) and the Bazel 8 compatibility changes for `rules_scala` 8.x (#1652). Contains a light editing pass over almost every Markdown file to resolve `markdownlint` warnings when editing in VSCode. Also added `.markdownlint.json` to silence rule `MD033/no-inline-html`, since several docs contain `<br/>` and/or `<table>` elements. - https://github.com./DavidAnson/vscode-markdownlint?tab=readme-ov-file#markdownlintconfig Performed other opportunistic grammar edits and added new information, including: - `docs/coverage.md`: Describes how to determine the default JaCoCo version used by `rules_java` - `scripts/README.md`: Updates `create_repository.py` docs extensively, and adds a section for `sync_bazelversion.sh` - Replaces `starlark` code fences with `py`, since the syntax is identical and editors seem to support it better. --- Since the next major release is imminent, ensuring the documentation accurately reflects all the changes since v6.6.0 has become an urgent priority. Rather than leave the old `WORKSPACE` APIs in place, which could lead to surprising failures, this change removes all of them. This also changes some code that still depended on some of these obsolete macros, including `scala_toolchains()`. Since all the toolchainization changes led to the entire project already using `scala_toolchains()` and `scala_register_toolchains()` exclusively, this proved a low risk refactoring. With some Bzlmod and Bazel 8 information already in place, very little will need to change when these implementations land. The commits that contain those implementations will also include their relevant documentation updates. * Update GitHub refs, minor grammar error in README It seems the README won't expand refs like #1482. This updates such refs to use the repo prefix, e.g., #1482. * More small README.md improvements * s/stanza/snippet/g Thanks to @bartoszkosiorek for pointing out in #1703 that "stanza" isn't a common word. That was my former English Lit major innie leaking out, applying a poetry term (a group of lines, like a paragraph) out of context. * Add Bzlmod repo scope change, `scala_toolchain` Explicitly notes that some `rules_scala` APIs may break, specifically `setup_scala_toolchain`. Part of #1482. Brought to my attention by @michalbogacz in a `#scala` thread in the Bazel Slack workspace, which was in the context of michalbogacz/scala-bazel-monorepo#26. - https://bazelbuild.slack.com/archives/CDCKJ2KFZ/p1740144886159909 * Update README.md per @grepwood's feedback in #1703 - Updates links not to use code tags, since it gives the appearance of multiple adjacent links. - Updates issue reference missing the `bazelbuild/rules_scala` prefix. - Moves paragraphs above "Getting started" `WORKSPACE` snippet to a new "Important changes in `rules_scala` v7.0.0 configuration" section following the snippet. * Update `scala_toolchains()` docstring Removes the reference to `@rules_scala_toolchains`, since that's not really a public interface detail. Prompted by a ping from @gergelyfabian in a Bazel Slack workspace direct message, asking about the docstring currently reflected on `master`. * Fix `WORKSPACE` snippet for `rules_java` 7.x The `WORKSPACE` snippet in the `README.md` now matches what's currently in all the other `WORKSPACE` files. I'd previously included the `rules_java` 8.x statements from my Bazel 8 compatibility branch in the `README.md` changes for `rules_scala` 7.x. @gergelyfabian tried the previous snippet from #1703, and it broke his build: - #1703 (comment) * Clean up cross-compilation.md, rm deprecated attr Includes a full editing pass over `docs/cross-compilation.md` and removes the `incompatible_use_toolchain_transition` attribute, which has been deprecated since before Bazel 6.5.0. - https://bazel.build/versions/6.4.0/rules/lib/globals?hl=en#rule The "Cross-build support tiers" could use extra review by someone more knowledgable about that aspect of `rules_scala`. Prompted by a suggestion by @gergelyfabian in #1703 to update a single line, but turned into a complete overhaul. * Fix `io_bazel_rules_scala`, version in README Removes a remaining, incorrect `@io_bazel_rules_scala` reference in `README.md`, as well as in the `.github/workflows/workspace_snippet.sh` script. Updates the `README.md` to use `<VERSION>` in place of `7.0.0` in the `WORKSPACE` snippet under "Getting started". Prompted by a couple comments by @gergelyfabian in #1703. I used the following command to confirm no more unintentional `io_bazel_rules_scala` references remain. (I'm leaving the `test_intellij_aspect.sh` script alone for now.) ```txt $ git ls-files | xargs grep 'io_bazel_rules_scala[^_]' .github/workflows/workspace_snippet.sh: name = "rules_scala", # Can be "io_bazel_rules_scala" if you still need it. README.md: name = "rules_scala", # Can be "io_bazel_rules_scala" if you still need it. README.md:- __`rules_scala` no longer requires the `io_bazel_rules_scala` repository test_intellij_aspect.sh: bazel test --test_output=errors --override_repository io_bazel_rules_scala="${rules_scala_dir}" --extra_toolchains=@io_bazel_rules_scala//scala:default_toolchain //aspect/testing/tests/src/com/google/idea/blaze/aspect/scala/... ``` There are still many `io_bazel_rules_scala_.*` references, most of them for internal toolchain dependency repos. The `@io_bazel_rules_scala_config` repository is the exception, which is a publicly documented interface. (We _could_ change it, as another potential known breakage for `rules_scala` v7.0.0.) * Remove `testing` parameter from `scala_toolchains` Removed in favor of using the existing `scalatest`, `junit`, and `specs2` parameters at @simuons's suggestion in: - #1482 (comment) Also updated the `scala_toolchains()` docstring slightly and added `doc` parameters to the `attrs` for `_scala_toolchains_repo()`.

bartoszkosiorek changed the title ~~Please add support to Scala 2.13.16 and 3.6.3~~ Please add support to Scala 2.13.16 and 3.3.5 Feb 14, 2025

bartoszkosiorek changed the title ~~Please add support to Scala 2.13.16 and 3.3.5~~ Please add support to Scala 2.13.16 and make new release Feb 14, 2025

bartoszkosiorek added a commit to bartoszkosiorek/rules_scala that referenced this issue Feb 14, 2025

Upgrade Scala 2.13 LTS to 2.13.16

f1fe5f5

Fixes: bazelbuild#1699

bartoszkosiorek mentioned this issue Feb 14, 2025

Upgrade Scala 2.13 LTS to 2.13.16 #1700

Merged

bartoszkosiorek added a commit to bartoszkosiorek/rules_scala that referenced this issue Feb 14, 2025

Upgrade Scala 2.13 LTS to 2.13.16

3da093c

Fixes: bazelbuild#1699

bartoszkosiorek added a commit to bartoszkosiorek/rules_scala that referenced this issue Feb 14, 2025

Upgrade Scala 2.13 LTS to 2.13.16

a7494c3

Fixes: bazelbuild#1699

bartoszkosiorek added a commit to bartoszkosiorek/rules_scala that referenced this issue Feb 14, 2025

Upgrade Scala 2.13 LTS to 2.13.16

daeae57

Fixes: bazelbuild#1699

bartoszkosiorek added a commit to bartoszkosiorek/rules_scala that referenced this issue Feb 14, 2025

Upgrade Scala 2.13 LTS to 2.13.16

dcaad25

Fixes: bazelbuild#1699

bartoszkosiorek added a commit to bartoszkosiorek/rules_scala that referenced this issue Feb 15, 2025

Upgrade Scala 2.13 LTS to 2.13.16

526cc82

Fixes: bazelbuild#1699

bartoszkosiorek added a commit to bartoszkosiorek/rules_scala that referenced this issue Feb 15, 2025

Upgrade Scala 2.13 LTS to 2.13.16

a9bd15f

Fixes: bazelbuild#1699

mbland mentioned this issue Feb 18, 2025

Update docs for version 7.0.0, remove old APIs #1703

Merged

mbland mentioned this issue Feb 20, 2025

Support Bzlmod and add rules_scala to bazel-central-registry #1482

Closed

simuons pushed a commit that referenced this issue Feb 26, 2025

Upgrade Scala 2.13 LTS to 2.13.16 (#1700)

2e59e88

Fixes: #1699

simuons closed this as completed in #1700 Feb 26, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Please add support to Scala 2.13.16 and make new release #1699

Please add support to Scala 2.13.16 and make new release #1699

bartoszkosiorek commented Feb 14, 2025 •

edited

Loading

bartoszkosiorek commented Feb 14, 2025 •

edited

Loading

WojciechMazur commented Feb 14, 2025

mbland commented Feb 14, 2025 •

edited

Loading

mbland commented Feb 14, 2025

crt-31 commented Feb 14, 2025

mbland commented Feb 14, 2025

bartoszkosiorek commented Feb 15, 2025

mbland commented Feb 18, 2025

mbland commented Feb 18, 2025

mbland commented Feb 20, 2025

Please add support to Scala 2.13.16 and make new release #1699

Please add support to Scala 2.13.16 and make new release #1699

Comments

bartoszkosiorek commented Feb 14, 2025 • edited Loading

bartoszkosiorek commented Feb 14, 2025 • edited Loading

WojciechMazur commented Feb 14, 2025

mbland commented Feb 14, 2025 • edited Loading

mbland commented Feb 14, 2025

crt-31 commented Feb 14, 2025

mbland commented Feb 14, 2025

bartoszkosiorek commented Feb 15, 2025

mbland commented Feb 18, 2025

mbland commented Feb 18, 2025

mbland commented Feb 20, 2025

bartoszkosiorek commented Feb 14, 2025 •

edited

Loading

bartoszkosiorek commented Feb 14, 2025 •

edited

Loading

mbland commented Feb 14, 2025 •

edited

Loading