Roadmap for sbt 1.4?

Congratulations for getting sbt 1.3.0 out!

Would it be possible to have more information about the roadmap for the next version of sbt?

In particular, I’d be curious to know what are the plans about sbt server. The documentation says that this is experimental and that LSP is supported. Do you plan to support BSP?

1 Like

timing

We were fortunate to get lots of help from the contributors for sbt 1.3.0, and were able to make some big changes. For sbt 1.4.0, maybe we should try to ship in 100 ~ 200d. (I’ve said that about sbt 1.3.0 too, but we should aim for it nonetheless)

specifics

One of the things I would be looking into is Zinc performance in large corporate codebase.

BSP support is something I’ve had on a short list of feature enhancement. (Related contribution would be welcome in this area)

Another nice-to-have that I’ve been hacking on-and-off is using build.properties file more. For example, giter8.version should be specified in there so the template author can specify the Giter8 version (much like how sbt works). Another idea that’s been brought up is allowing build authors to specify JVM flags in there.

If anyone has Christmas wishes, I’d be happy to get feedback in this thread, and maybe contributors can get ideas.

2 Likes

Why do those have to wait for 1.4.0?

  1. Every fresh code has bugs, so feature enhancements need to go through RC cycle. (Patch releases come out without RCs)
  2. Extending the life of patch 1.2.x or 1.3.x is one of major causes of delaying the feature release.

Thanks Eugene for your response!

Another thing that comes to my mind: I remember there has been some work to improve “matrix configurations” support. What are your thoughts about it?

The experiments in sbt-projectmatrix is shaping up. It needs some more tweaking, but this might be a good candidate to merge into mothership if people want the feature.

3 Likes

+1000 to that, but at this point I think the best way to achieve this would be to simply bundle the bloop sbt plugin with sbt, like 1.3 did with the coursier sbt plugin. This would also bring all the other improvements bloop brings (classloader handling, build pipelining, …) for free.

Currently, the bloop sbt plugin does not much apart from generating a bloop configuration that you can then use with bloop. So, bundling the bloop sbt plugin within sbt would not help, in its current state, if I understood correctly.

So, I guess what we need for a working integration is to make sbt delegate compilation to the bloop server, and delegate the “sbt server” to the bloop server. Maybe @jvican can confirm or fix this assumption?

That being said, I’ve seen that mill chose to not use bloop to support BSP (see lihaoyi/mill#664), although there is a mill integration in bloop, which does provide BSP for free. I’m not familiar enough with either bloop or mill to fully understand the reasons for this, but it seems that the mill integration in bloop can not take advantage of some features of mill (I guess this is by design, because bloop is designed to be build tool agnostic). I’m wondering whether the same kind of limitations would apply if we were trying to get BSP support (and “all the improvements bloop brings for free”) by relying on the sbt bloop integration?