> 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.
Scala 3.3 is expected to release early next week which is likely going to be sooner than any milestone release. Also do note there is another strong reason to have milestone for Scala 3.3, the upstreamed Parboiled2 changes from pekko-http will also only get released alongside Scala 3.3. > 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? For all intents and purposes within Pekko the @inline in Scala 2 works the same as inline keyword in Scala 3 and for this reason I wouldn't recommend merging the inline changes unless we know its working for all of the Scala versions we support (2.12 to 3.3). Currently it's working for Scala 2.12 and 3. Another thing to note is that @inline does nothing in Scala 3 so we have to replicate the the source for Scala 3 specifically. Regarding qualms on the safety of inline, unlike the older Scala 2 inline the latest one is not going to inline anything unless it's safe to do so (which is actually the single problem we have right now, something which should be inlined is not for 2.13). Regardless its easy to verify if the inliner is causing problems by inspecting the diff in JVM bytecode and the PR won't be merged unless this is done, whether it makes it for 1.0.0 or not. On Sun, 21 May 2023, 18:56 PJ Fanning, <[email protected]> wrote: > 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] > >
