Publish for 2.13.0-M4 #2267
Comments
|
I took a few minutes to look at this. In no particular order:
|
|
|
machinist 0.6.5 is out now for M4, so is ScalaTest 3.0.6-SNAP1 |
|
Awesome, if nobody beats me, I'll create a PR enable 2.13M4 and drop 2.10 after 1.2 release. |
|
1.3.x is kind of a long time to wait for 2.13 support. I'm a little vague on the timelines, but I get the impression that 2.13 will actually be released by that point. Given how foundational cats is to such a large swath of the ecosystem, waiting that long is probably not a good idea. I know the issues with scalacheck and what not, but it's probably worth fiddling around with annoying matrix builds, given the cross-build hell this kind of delay is about to unleash on the ecosystem. |
|
This issue is another reminder of the non-zero costs of dependencies. It would be nice to see about minimizing dependencies (would some of our dependencies be open to being submodules, e.g. machinist, discipline, so more of the cats ecosystem is publishable atomically). |
|
@johnynek The downside to moving things like machinist and discipline into cats as submodules is then they cannot be published apart from cats. So that's great for cats and everything self-contained within the repository… and terrible for everything else downstream. Philosophically, you either have to go all-in on the monorepo or all-in on polyrepo, and there's really no middle ground. OSS libraries can't be uniformly monorepo because the extension set is open, so it follows that we should actually avoid submodules unless they really are intrinsically connected to the main project (e.g. cats-laws). More importantly, the problem at hand here has absolutely nothing to do with the loosely coupled nature of the cats ecosystem. Rather, it is simply the fact that part of the Scala ecosystem is dropping support for 2.10 before other parts. Scalacheck not providing a unified release across 2.10/2.11/2.12/2.13 is totally understandable (that's four versions!), but it ultimately prevents discipline from doing the same without matrix shenanigans, which in turn prevents cats from doing the same without matrix shenanigans. But cats effectively promises (via binary compatibility) to have 2.10 support for a while, which leads us to the pickle we're in now. In my view, cross-build availability shouldn't be considered part of the binary compatibility contract. Doing so just bogs down the entire ecosystem and makes it effectively impossible for significantly-downstream projects from ever dropping support for Scala versions, or in this case makes it effectively impossible for significantly-downstream projects to keep up with the Scala release cadence (which is a much more serious problem!). Cats is a foundational library. Without putting too fine a point on it, it seems absolutely unacceptable to the ecosystem if it does not have a viable 2.13 cross-build at least leading into the RC process. Lacking that cross-build delays the entire FP middleware ecosystem (e.g. fs2, http4s, etc), which is now several layers deep (e.g. cats-effect, shims). There are just so many moving parts here, most of which we don't control, all of which are blocked on this from the standpoint of cross-build availability. Point being: punting until 1.3.0 really isn't a viable option. That's far, far too long to wait for a dependency which is as upstream as cats. |
s/cross-build/build/ and I agree. In addition, Cats binary compatibility guarantees should be off the table for Scala milestone/release candidate builds. Would a non-cross-built release of 1.2 for for 2.13.0-M4 be too much of an effort to produce? That's pretty much what I did for shapeless 2.3.3 and that's allowed downstream libraries to start making progress on updates for 2.13.x. Aside from holding up the rest of the ecosystem it makes it a lot harder to be confident that changes in 2.13.x haven't broken Cats in some subtle and unpredictable way. See here for an example ... I'd love to be able to got through the same exercise for Cats but, in the absence of a build, it's more effort than I have time for. Bottom line: if you don't get a 2.13.x build out ASAP then you won't have a legitimate complaint if there are nasty surprises subsequently. |
|
The plan I suggested on gitter is to release 1.2.0 on 2.10 -2.12 first, cut a branch, update to 2.13.0-M4 and release 1.2.0 for 2.13.0-M4. |
|
Also worth checking up on (these normally crop up when catalysts is compiled, but needed by cats as well:
Once tut is done, sbt-microsites is also needed. sorry cant do these myself....holidays 😄 |
|
all of cats's dependencies (or the subset the community build actually uses/needs, anyway) are now green in the Scala 2.13 community build, which is good news that means the door is now open to try to get cats itself green, too. but currently it doesn't compile seen at https://scala-ci.typesafe.com/job/scala-2.13.x-integrate-community-build/1226/consoleFull |
|
tut ticket is tpolecat/tut#205... maybe @tpolecat could use some volunteer help |
|
tut 0.6.6 is out for 2.13.0-M4, sorry for the delay |
scala/scala#6918 I have sent pull request which add deprecated reduceOption etc. |
|
I have a PR that I'm just finishing for the new sbt-crossBuild stuff...20 minutes |
|
|
For future reference, we need to add scala-logging to the (indirect) build deps see lightbend-labs/scala-logging#127 (used by scoverage scoverage/scalac-scoverage-plugin#225 (comment) ) |
fixed. another new errors scala/bug#11009 https://scala-ci.typesafe.com/job/scala-2.13.x-integrate-community-build/1236/consoleFull |
|
Seeing these errors is making me nervous that 2.13 is going to be massively painful to adopt in big code bases. I saw the 2.8 -> 2.9, 2.9 -> 2.10 and 2.10 -> 2.11 transitions at Twitter. Those took months of effort. I’m worried big users will be putting off 2.13 for years. Just free floating anxiety. |
All the more reason for users to try out 2.13.X, early . That currently excludes all cats users and users of cats related projects, as there have been zero releases of cats for 2.13.X. Related open PR, btw - #2323 |
|
@johnynek y'all at Twitter might try a pilot with twitter-util? I've opened a ticket here: twitter/util#219 in general, the collective experience so far seems to be that we're discovering and fixing lots of little issues that are getting fixed for M5, but nobody that I know of has hit any actual blockers yet. (oops, jinxed it...) we could discuss further on that ticket (if it's specific to stuff you're hitting) or discuss 2.13 upgrade stuff in general on https://contributors.scala-lang.org available dependencies, and links to "please publish for M4" tickets, are listed at https://github.com/scala/make-release-notes/blob/2.13.x/projects-2.13.md |
|
@SethTisue, I sent some feedback to contributor.scala-lang.org before about issues we ran into with trying to migrate twitter/util. The verdict seemed to be that it was just going to be incredibly hard to migrate to 2.13 and there wasn't much you could do about it? |
|
@mosesn @johnynek let's continue there, I guess, if there are points you've raised that haven't been covered yet. (we do consider it normal — not desirable, but the best we can do — that some projects that integrate especially closely with collections will need Scala-version-specific source directories.) |
|
@xuwei-k are you stuck, is there something we should be discussing? (perhaps this is a case where the file in question will need to be duplicated in Scala version specific source directories?) |
ghost
mentioned this issue
|
Update: I managed to get all dependencies to 2.13-M4 (had to publishLocal sbt-scoverage but I think they'll release soon). |
deprecation warnings are expected when cross-compiling. (using scala-collection-compat would eliminate many of them; you could take it on as a dependency, or you might decide that you don't want to deal with the extra dependency, either as maintainers, or because you don't want to impose it on your users, or both. cherry-picking the source code for the pieces you need into your project seems like a possibility as well, e.g. it's unfortunate that scalac doesn't offer fine-grained suppression of warnings, but you might consider using a third-party solution such as https://github.com/ghik/silencer most projects are getting by with having Scala-version-specific versions of a few key source files (typically ones that interact directly with |
|
@kailuowang The build file is a mess, but I've got catalysts compiling/testing OK for 2.13.0-M4. I'll continue later/tomorrow morning a final version, Please shout here if you need something pushed sooner |
|
@BennyHill thanks for the update. Take your time. Catalyst isn't a blocker right now. |
|
@SethTisue thanks for the info, very helpful |
|
@SethTisue Only slightly annoying issue I had was with macro annotations, fixed by adding I'm OK now, but for the next guy, where is that change nicely documented? And would a more friendly error message be suitable here? Like "add the option...." |
|
fyi, I found it by greping the simulacrum build file |
in the M4 release notes, https://github.com/scala/scala/releases/tag/v2.13.0-M4 fsvo of "nicely" anyway
note that this error message isn't coming from the Scala compiler, it's coming from some particular macro annotation in some dependency of yours it's unfortunate that we ended up in a situation where everyone pasted this error message into their code from the example in macro annotation documentation, so we can't update it centrally. |
Nope...from my code 😄 I'll fix that per scala version, but might be a helping hint to add for others, your call. Many thanks, btw 👍 |
|
published. The residual issues can be tracked in #2347. Closing for now. |
Here we go again...
The text was updated successfully, but these errors were encountered: