@PJ Fanning <[email protected]> Shall we proceed with the release? I didn't receive a response from any of the Scala people.
On Mon, Jul 17, 2023 at 5:22 PM Matthew de Detrich < [email protected]> wrote: > > Pekko HTTP does not use pekko-remote (where the issue is). It's not > very tidy but only Pekko HTTP users who also need Pekko Remote and > Clustering features would need to upgrade to Pekko (Core) 1.0.1. > > Yes I am aware, but as you have hinted the bigger problem is trying (as > much as possible) to reduce how many occurrences of Pekko 1.0.0 there are > being used in the wild and having the initial Pekko Http 1.0.0 depend on > Pekko 1.0.0 doesn't help in this regard however as I said I am willing to > accept this as long as the scala team doesn't come back with something more > critical > > On Mon, Jul 17, 2023 at 5:18 PM PJ Fanning <[email protected]> wrote: > >> Pekko HTTP does not use pekko-remote (where the issue is). It's not >> very tidy but only Pekko HTTP users who also need Pekko Remote and >> Clustering features would need to upgrade to Pekko (Core) 1.0.1. >> >> On Mon, 17 Jul 2023 at 16:11, Matthew de Detrich >> <[email protected]> wrote: >> > >> > So my opinion is to release Pekko 1.0.1 as soon as we can. Even though >> this >> > was picked up in Scala 3.3.2 RC (The Scala team added incubator-pekko to >> > their community build which basically means incubator-pekko gets >> compiled >> > against the latest Scala version on a nightly basis), the undefined >> > behaviour is for any version of Scala 2/Scala 3, i.e. reading the Scala >> 2 >> > spec from >> > >> https://www.scala-lang.org/files/archive/spec/2.11/01-lexical-syntax.html >> > >> > > The ‘$’ character is reserved for compiler-synthesized identifiers. >> User >> > programs should not define identifiers which contain ‘$’ characters. >> > >> > This means hypothetically any future change to Scala compiler >> (inclusive of >> > Scala 3 which is how the problem got detected in the first place) can >> > create undefined behaviour so it's in our best interest to at least get >> > Pekko 1.0.1 with this fix out as soon as we can. That being said, since >> the >> > affected code is private for Pekko there could also practically be zero >> > issues so I don't think it's worth it to delay a pekko-http release over >> > this (although its somewhat annoying because it does mean pekko-http >> will >> > get released with a "broken" version of pekko and we would then ideally >> > want to make another future pekko-http release quickly using the fixed >> > pekko 1.0.1). On this point I would wait until tomorrow to see what the >> > Scala compiler team says and how critical it is, if it's deemed very >> > critical then delaying pekko-http until pekko 1.0.1 is released to me >> makes >> > sense (but irregardless if we get a response or not we should ideally >> start >> > releasing the fixed pekko 1.0.1 tomorrow). >> > >> > Regards >> > >> > On Mon, Jul 17, 2023 at 4:32 PM PJ Fanning <[email protected]> >> wrote: >> > >> > > Hi everyone, >> > > >> > > Due to a class name issue [1], we are planning to produce an RC1 for >> > > Pekko 1.0.1 over the next day or two. >> > > >> > > So far the issue appears in compatibility testing for Scala 3.3.2-RC1 >> > > and hasn't been reported elsewhere. The class in question is in >> > > pekko-remote. >> > > >> > > The code is package private so I don't think it will cause major >> > > issues when we get 1.0.1 released (i.e. users switching from v1.0.0 to >> > > v1.0.1 are very unlikely to have any issues relating to us changing >> > > the problematic class name). >> > > >> > > There is nothing in the `main` branch yet that we wouldn't want to >> > > include in the v1.0.1 release so we will make the RC from the `main` >> > > branch. >> > > >> > > I still think we can also press on with a Pekko HTTP 1.0.0-RC1 in the >> > > coming days. We might delay it by a couple of days but I think we can >> > > release Pekko HTTP 1.0.0 with a dependency on Pekko (Core) 1.0.0 but >> > > release note that users should use Pekko (Core) 1.0.1 when it is >> > > available. >> > > >> > > The alternative is to delay Pekko HTTP 1.0.0-RC1 until Pekko (Core) >> > > 1.0.1 is released. With the current 2 phase voting requirements and >> > > the build process that we have, that probably means delaying Pekko >> > > HTTP 1.0.0-RC1 by 2 weeks. >> > > >> > > Feel free to share your opinions on this thread. >> > > >> > > Regards, >> > > PJ >> > > >> > > [1] https://github.com/apache/incubator-pekko/issues/491 >> > > >> > > --------------------------------------------------------------------- >> > > To unsubscribe, e-mail: [email protected] >> > > For additional commands, e-mail: [email protected] >> > > >> > > >> > >> > -- >> > >> > Matthew de Detrich >> > >> > *Aiven Deutschland GmbH* >> > >> > Immanuelkirchstraße 26, 10405 Berlin >> > >> > Amtsgericht Charlottenburg, HRB 209739 B >> > >> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen >> > >> > *m:* +491603708037 >> > >> > *w:* aiven.io *e:* [email protected] >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > -- > > Matthew de Detrich > > *Aiven Deutschland GmbH* > > Immanuelkirchstraße 26, 10405 Berlin > > Amtsgericht Charlottenburg, HRB 209739 B > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > *m:* +491603708037 > > *w:* aiven.io *e:* [email protected] > -- Matthew de Detrich *Aiven Deutschland GmbH* Immanuelkirchstraße 26, 10405 Berlin Amtsgericht Charlottenburg, HRB 209739 B Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen *m:* +491603708037 *w:* aiven.io *e:* [email protected]
