If anyone is looking to help push Pekko core libs [1] to a 1.0.0 release, the most useful thing to do is try out the latest snapshots [2].
The plan is to do minimal changes unless big issues are found. With Scala 3.3.0, it's my opinion that we could do the M0 snapshot publish before this is ready. I doubt whether a large proportion of the people waiting for the release need Scala 3 support and the jars built with Scala 3.2.2 are expected to work with Scala 3.3. Our Scala 3.3.0-RC6 build did not show any significant issues. If Scala 3.3.0 is released shortly after we do our M0 snapshot, we could uptake Scala 3.3.0 and possibly so a M1 snapshot. I'm not convinced that we need to do the inliner changes either [4]. Akka build had them disabled and I'd prefer not wait to wait for the Scala fixes to support them. One question I would have is if the Scala 3.3 `inline def` changes are possibly something that we could merge now or do the `@inline` annotations that they replace enough as is? If we could agree not to wait for these items, we could just do the M0 snapshot in the next few days and look to do the 1.0.0 RC1 in maybe a week or 2's time. We have the MiMa plugin to check for binary compatibility issues after the 1.0.0 release. I think we can live with making some small binary incompatible changes if we document them. At the moment, it feels like we are damaging Pekko by not releasing. [1] https://github.com/apache/incubator-pekko [2] https://repository.apache.org/content/groups/snapshots/org/apache/pekko/ [3] https://github.com/apache/incubator-pekko/pull/270 [4] https://github.com/apache/incubator-pekko/pull/305 On 2023/05/21 14:09:24 Matthew Benedict de Detrich wrote: > > A docker release is just a convenance to your users, it’s not an official > release. > > The docker image is not a convenience package (this also foesnt make sense > since Pekko is a library), it's for creating a reproducible environment for > making a release. There are other ways to do this such as a VM image but > docker is the least friction solution. > > > Why wait? The longer you do so the harder it may be to grow a community > around this project. Making releases involves the community, they can > provide feedback and make contributions to improve the project. > > Because since Pekko is a library that follows an ABI we can break users if > not careful and that is one of the most negative ways you can impact Pekko > users. > > > Perhaps the project needs to consider a change to this approach? > > This is an expectation for Scala/Java libraries so it's not really going to > change. It's not any different to Apache Commons also maintaining binary > compatibility (for example), it's just that it's harder for us since Pekko > is a cross Java/Scala library. > > On Sun, 21 May 2023, 15:00 Justin Mclean, <[email protected]> wrote: > > > Hi, > > > > > A lot of our complications for the release come from the fact that Pekko > > is > > > a library with very strict expectations for binary compatibility.(these > > > expectations are inherited from Akka). > > > > Perhaps the project needs to consider a change to this approach? > > > > > Thankfully as mentioned before the majority of the critical changes that > > > fulfil these expectations have already been done. Aside from further > > > documentation changes and getting the docker release working, > > > > A docker release is just a convenance to your users, it’s not an official > > release. > > > > > the major thing we are waiting for is Scala 3.3 LTS which is expected to > > come out > > > next week. > > > > Why wait? The longer you do so the harder it may be to grow a community > > around this project. Making releases involves the community, they can > > provide feedback and make contributions to improve the project. > > > > Kind Regards, > > Justin > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
