Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: Remove files for no longer used versions #3263

Merged
merged 1 commit into from
Jul 21, 2023

Conversation

tgodzik
Copy link
Collaborator

@tgodzik tgodzik commented Jul 21, 2023

No description provided.

@tgodzik tgodzik requested a review from kitbellew July 21, 2023 11:49
@tgodzik
Copy link
Collaborator Author

tgodzik commented Jul 21, 2023

No need to compile or test it if we don't release for those versions.

Copy link
Contributor

@kitbellew kitbellew left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thank you, my omission!

@tgodzik tgodzik merged commit 525a7c4 into scalameta:main Jul 21, 2023
24 checks passed
@tgodzik tgodzik deleted the remove-old branch July 21, 2023 12:34
@agboom
Copy link

agboom commented Feb 26, 2024

Hi @tgodzik, sorry for bumping an old PR, but could you maybe give some context as to why these old Scala versions are removed?

Recently some of our builds started breaking, indirectly because of the removal of these old versions. We use scalac-scoverage-plugin for measuring coverage, which depends on Scalameta. A few days ago this plugin removed these versions in this PR, which was causing to break our builds on Scala versions older than 2.13.10. To be fair, Scalameta still supports Scala through 2.13.8, so the Scoverage plugin seemed to go a bit further. My bad, I was looking at this PR, but main looks like it supports through 2.13.10.

The reason this happened is because we use an Ivy revision range (i.e. "[2.0.6,3)") in the scoverage plugin to make sure to support a broad enough range of Scala versions (since every patch needs a new plugin release, this reduced the maintenance burden). Keeping the old versions supported would mitigate this, but of course there may be a good reason to remove old versions, hence my question.

@kitbellew
Copy link
Contributor

@agboom our release builds were taking hours and failing most often. after discussing this issue on discord, we agreed to support only the last four patches of the last two minor versions of scala2 (2.12 and 2.13) and the latest 2.11; and scala3 is not yet supported, except, of course, for parsing.

so as 2.13.13 came out, 2.13.9 was removed (see #3566).

@kitbellew
Copy link
Contributor

scoverage does the same, perhaps because of us: https://github.com/scoverage/scalac-scoverage-plugin/blob/main/build.sbt#L16

@agboom
Copy link

agboom commented Feb 26, 2024

Thanks for explaining @kitbellew, that makes sense. I should've looked on discord first 🙈
You're right, scoverage explained they follow suite: scoverage/scalac-scoverage-plugin#604 (comment)

We do try to keep our Scala versions up-to-date, but we have a lot of projects with different Scala patch versions, and a single sbt plugin that needs to support all those Scala versions. We either need to step up our Scala upgrade process or find a way to match the right scoverage plugin version to the right Scala version. But that's kind of out of scope of this discussion

@tgodzik
Copy link
Collaborator Author

tgodzik commented Feb 26, 2024

We generate a list of supported versions here https://github.com/scalameta/metals/blob/main/project/SemanticDbSupport.scala#L3

So we can match semanticdb version to Scala version. Might be useful for you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants