chore: update dependencies - #258
Conversation
|
Hello again, and thanks for looking into this. Happy to merge this if you revert two changes: the one for Scala (should stay at 3.0.2) and the one for Scala.js (should stay at 1.7.1). The reason is that both these releases are only binary-backwards-compatible, but not binary-forwards-compatible. In practice this would mean that we'd force users to upgrade. If we stay on the older versions instead, users can upgrade if they want to, but they don't have to. This is also aligned with the versions our dependencies use (e.g. cats-core and cats-effect are also still on 3.0.2 and 1.7.1). Once our upstream dependencies move, we can move, too, as users won't have a choice at that point anyway. Btw. on a general note you probably noticed I am currently a bit slow with both, reviewing PRs and my own work on Laika, too. This will most likely stay like that for a while, but for users it won't make much of a big difference, because there is no imminent release planned at the moment, and for 0.19 (which will take a few months) I will definitely look at all PRs before that release, so that everything that is good to merge will be part of that release. |
|
Part of the problem is that fs2 upgrades eagerly and is already on 3.1.1 and Scala.js 1.9.0. So this pins you to an old fs2 and by extension, an old http4s, which is not ideal. Scala 3.1.2 should improve the forwards compatibility situation with the new In any case there's no rush at the moment so there's time to see what makes most sense. |
Sure. I will revert them. By the way, how about using scala-steward for dependancy updates? I think it is sometimes noisy, but Laika depends on small number of external libraries and has a lot of unit tests, it is worth trying. |
Yeah, no worries. I am not in a hurry. I just have spare time to improve this lib😉 Thank you for maintaining this lovely library. |
|
@armanbilge oh, I wasn't aware of the fs2 move, I only checked cats and cats-effect, as they are the main dependencies at the moment (http4s is only used in the preview server). I'm surprised that Typelevel projects took different paths here. I also noticed that apparently http4s does not do early-semver, right? Because it integrated those minor upgrades in an 0.23 patch release, which would not be possible under early-semver. @i10416 under these circumstances Laika might move to Scala 3.1.x, too, at least if we introduce fs2 to the io module for 0.19 which is highly likely. No need to revert then at the moment, I might merge this as is. |
Yeah, it was pretty controversial unfortunately :( discussion in:
http4s does do early semver, in the sense of guaranteeing backwards binary-compatibility throughout the 0.22/0.23 minor series. (Although possibly not as strictly as Laika, I think you also preserve forwards compatibility?). In any case, bumping to Scala 3.1 was not an easy choice, but fs2 kind of decided for us. Discussion was in: In Scala 3.1.2 there will be a new flag |
|
I actually thought that the early-semver definition demands that a patch release is binary-backwards-compatible and source-backwards-compatible, which would prevent integration of any upstream dependency with a minor bump, but now that I checked it I cannot find any reference to that, so I probably remember it the wrong way. The only good thing about the Scala 3 dependency confusion is that the adoption is still so low that it feels unlikely there'll be many complaints about forcing the update. In particular in Laika's case, where many use it as an sbt plugin, which means being on Scala 2.12. Regarding the new flag, the linked tickets contain recommendations not to use it yet for publishing non-experimental libraries. You think Typelevel projects will adopt it anyway? |
Yes, that is recommended here: https://docs.scala-lang.org/overviews/core/binary-compatibility-for-library-authors.html#recommended-versioning-scheme However, while most projects focus on binary-compatibility, only a few are concerned with source compatibility. Cats and Cats Effect follow this rule, but fs2 does not for example.* If your project is in 0.x, then it is especially problematic. Because, strictly speaking, adding any new features can be source-breaking then you can't develop your project without a breaking version bump. This would force the entire ecosystem to bump versions and re-release just so you can add a small new feature to your library 😉 so for http4s this would be impractical.
I assume it will no longer be experimental once it's officially released in 3.1.2? If it is still experimental, then I'm not sure what will happen. *Edit: actually there is a nuance here. There is "strict" source-compatibility, where you cannot add new features (since they can be inadvertently source-breaking). There is also "relaxed" source-compatibility, where you can add new features, but you don't deliberately break existing sources (e.g., by making an implicit to non-implicit, etc.). While only a few projects are concerned with strict source-compatibility, most I know do emphasize "relaxed" source-compatibility including fs2 and http4s. |
|
Tbh, I'm even more confused now. 😄 I interpret the link you posted as actually confirming I was wrong: A patch release is described as binary- and source-compatible only when it is not in the 0.x range. |
|
Woops, yes, you are right about that! Sorry for the additional confusion :) |
|
Thanks @armanbilge for a lot of insights. Compatibility is often hard problem for Scala library authors. @jenshalm now that this PR was merged, I start working on #257 |
3 participants
No description provided.