-
Notifications
You must be signed in to change notification settings - Fork 14
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
Upgrade Scala Native to 0.5.1 #45
Conversation
CI failures include:
|
I think you can set a previous release missing somehow so that doesn't error - that might just be |
@ekrich Thanks for the hint! Ignoring a specific version worked by setting empty to |
Sorry for the delay here: I'm insufficiently familiar with the relevant parts of the ecosystem to be sure to make the right version judgments here. However: If we drop support for things, we need to bump the major version. Is this necessary to support Scala Native or can we do without? Because in the latter case, I do not think we should do it just because. |
@gzm0 if I understand the PR correctly, we're dropping only support (cross-compilation target) for an old version of Scala (2.11). That shouldn't require a major bump release. The code of the library is perfectly backwards compatible. |
That's irrelevant. If you do not publish it a Scala 2.11 cannot use it anymore. Scala 2 libraries need to be published for the minor Scala version. A library published for 2.11 cannot be used with 2.12 and vv. |
Actually, a similar comment applies to Scala native itself: How are libraries published for Scala native 0.5.x and Scala native 0.4.x published? If they are not compatible, we should probably cross compile & publish for Scala native 0.4.x and 0.5.x. |
Yes. All of this is true, no disagreement there. But at the same time, this doesn't warrant major bump of the library in question. At least it didn't warrant for any libraries which dropped Scala 2.11 and Native 0.4.x and adopted Native 0.5.x. E.g.
No major bump.
Nobody does that from what I've seen. Library developers stop cross-compiling to 0.4.x and start cross-compiling to 0.5.x in one commit/PR. |
I agree with @sideeffffect on the versioning aspect. We need a major version bump if we fragment the ecosystem. That is true only if the things which are still supported are incompatible with previous versions. A library that still supports 2.11 will always be able to stay on the old version, because it could not possibly depend on the third library requiring the new version of portable-scala-reflect (because such a new version would not exist for 2.11). Here I think a minor version bump would be enough. That said, I don't think I understand why it is even necessary to drop any support here? It seems we could keep expanding our build matrix instead, as we usually do? |
Of course, that's entirely possible. But it's just more load on library maintainers (which in this case is you guys ❤️ ). And in practice people don't do that. This library also isn't cross-compiled to Scala.js 0.6.x. And the consensus in the Scala Native community is also dropping 0.4.x immediately (see com-lihaoyi above). But if that's what you'd prefer, I'm sure that wouldn't be a problem, the PR can accommodate this approach. |
FYI sttp, tapir and other SoftwareMill libs are also switching directly to 0.5.1 without a major version bump. |
MUnit took the approach where they moved to 0.5.x but manually released artifacts for 0.4.x (see: mvn and discussion) for a single version - it doesn't transitively force their users to update dependencies when they want to only want to change Scala Native version. Not all libraries choose this, but if all of my dependencies did it, I would release 1 version for both 0.4 and 0.5 by hand, to make it easier on my users. |
OK. I think I understand now why we do not need a major version bump to drop support for cross versioned things: The version is mostly relevant on the artifacts and not on the git repository itself. So for things we drop support, an artifact with the new version simply doesn't exist.
|
Not at all. |
Is there any think blocking this PR? If yes, how can I help moving it forward? There's a lot of interest in getting this merged and released, because of lot of transitive dependents this project has. |
Basically this PR changes too much. If you do not want to wait on @xerial , I suggest opening a new, minimal PR. |
I'll try making an alternative tomorrow that only adds support without breaking anything. |
@gzm0 what do you mean? I see only changes in sbt setting to enable Scala Native 0.5.x. What changes do you think should be left out? |
@sjrd FYI. The only reason I needed to drop Scala.js 0.6.x support is due to this missing dependency error:
https://github.com/portable-scala/portable-scala-reflect/actions/runs/8760907044/job/24050014845 |
Superseded by #49 and other PRs that came before it. Thanks for pushing us in the right direction. Version 1.1.3 is now on Maven Central with Scala Native 0.5.x support (and everything else that was supported in 1.1.2). |
Upgrade Scala Native to 0.5.1.
Ideally, Scala 3 should be supported. However, since the macro-based JVM code needs to be rewritten for Scala 3, it is not included in this PR.