If anyone is very willing to support Java 8, they could consider maintaining a 1.4.0 version afterward. Of course, I personally am unwilling to do so because our internal systems have all been migrated to Java 11 or Java 21.
何品 kerr <[email protected]> 于2025年11月13日周四 12:58写道： > I think we should release version 1.3.0 as soon as possible; it's already > enough. If anyone is willing, they can check what other features we can > migrate. Otherwise, it's good enough, and we should quickly switch to > version 2.0.0 and Java 17. This branch is more worthy of our time as > volunteers. > > 何品 > > > kerr <[email protected]> 于2025年11月13日周四 12:48写道： > >> I believe we should have all the features of the Akka core. Since this >> version is already part of Apache 2.0, we should have all the features, >> allowing us to offer what others have. As for user feedback, I think users >> only report problems when they encounter them; not everyone visits GitHub. >> Most people probably just chat with colleagues or complain on messaging >> apps. >> >> Of course, openly speaking, Akka can also pick code from Pekko, >> complementing each other. Pekko proactively identified several issues in >> new Scala versions, driving Scala fixes and paving the way for a smooth >> upgrade of Akka to Scala later. Currently, Akka seems to be focusing >> primarily on its agentic system, and I've seen an MCP implementation on >> Pekko. Therefore, to better serve users, we should carefully review new >> Akka releases. After all, every implementation has a reason. However, since >> we are not providing a commercial service, we can potentially move faster >> in terms of binary compatibility; for example, we removed a lot of code in >> 2.0.0. >> >> My personal suggestion is that we align with Akka 2.7.0 in version 1.3.0, >> avoiding any disruptive changes. Version 2.0.0 should include all the >> features of Akka 2.7.0, and then prepare a new version, such as 2.1.0, with >> the features of Akka 2.8.0. Alternatively, we could postpone Pekko 2.0.0 to >> integrate Akka 2.8.0 features, which would give us more development time. >> Only in this way can we better serve our users and expand the community. >> >> 何品 >> >> >> kerr <[email protected]> 于2025年11月13日周四 12:27写道： >> >>> I think 2479 will not make it because it currently breaks Mima. But >>> https://github.com/apache/pekko/pull/2486 seems ok. >>> >>> I think we should get 1.3.0 out soon, because users may switch to Akka >>> 2.7.0 because of the new behavior api for Java 21's pattern matching. >>> >>> https://github.com/CajunSystems/cajun, a new actor library, advertises >>> that too. >>> 何品 >>> >>> >>> PJ Fanning <[email protected]> 于2025年11月12日周三 17:37写道： >>> >>>> I think PR 2479 is a workable solution. If there are no strong >>>> objections to it, we could get it into 1.3.0. >>>> >>>> Let's delay the RC1 for 1.3.0 for a week or two to allow a discussion >>>> to happen. >>>> >>>> On Wed, 12 Nov 2025 at 09:46, Matthew de Detrich <[email protected]> >>>> wrote: >>>> > >>>> > On another note and on the topic of making a javadsl/scaladsl for >>>> > ActorSystem, in >>>> > exploring the option of creating a non-source breaking smooth >>>> transition >>>> > from 1.3.0 >>>> > to 2.0.0 I made a PR at https://github.com/apache/pekko/pull/2479, >>>> see >>>> > https://github.com/apache/pekko/issues/2093#issuecomment-3520511719 >>>> > >>>> > I think it would be good to make an "executive" decision on the course >>>> > forward, if >>>> > we care about ActorSystem in Pekko 1.3.0 being source compatible with >>>> Pekko >>>> > 2.0.0 then we would need this PR to be merged for 1.3.0. >>>> > >>>> > On the other hand, if we wan't a cleaner API and don't worry about >>>> source >>>> > breakage >>>> > in 2.0.0, that PR isn't needed at all and it would also give us some >>>> > breathing room as >>>> > we only need to target Pekko 2.0.0. >>>> > >>>> > Thoughts? >>>> > >>>> > On Tue, Nov 11, 2025 at 3:31 PM Matthew de Detrich < >>>> [email protected]> >>>> > wrote: >>>> > >>>> > > > I don't personally believe that we need to port everything from >>>> Akka >>>> > > releases as they become available under the Apache license. I would >>>> > > prefer to concentrate on bug fixes and test coverage. Enhancements >>>> if >>>> > > people want them but I don't think we should grab them without >>>> > > evidence they are wanted by Pekko users. >>>> > > >>>> > > I actually disagree here, although within reason. For me, if there >>>> are >>>> > > changes >>>> > > that are isolated and easy to port then we should do that (if >>>> someone is >>>> > > willing >>>> > > to do it), it's better for end users and there is no argument >>>> against it >>>> > > aside from >>>> > > rushing a 1.3.x release. >>>> > > >>>> > > I understand that we need more tests and bug fixes but it's not a >>>> zero sum >>>> > > game, and >>>> > > in any case the Akka devs are very diligent in adding tests to any >>>> > > features that they >>>> > > implement so porting back changes is not going to change our status >>>> quo >>>> > > very much. >>>> > > >>>> > > And to close off, I wouldn't rely that much on user feedback when >>>> it comes >>>> > > to Pekko >>>> > > because it's historically not a very good way to gauge what >>>> features users >>>> > > want. >>>> > > Generally speaking people complain when there is a bug/something is >>>> not >>>> > > working >>>> > > (my personal theory for behind this is that its a holdover from how >>>> Akka >>>> > > was managed, i.e. >>>> > > Akka being BDFL and driving the project and our users haven't >>>> transitioned >>>> > > to a >>>> > > community mindset fully). >>>> > > >>>> > > Kind regards, >>>> > > Matthew >>>> > > >>>> > > On Sat, Nov 8, 2025 at 8:24 PM PJ Fanning <[email protected]> >>>> wrote: >>>> > > >>>> > >> I don't personally believe that we need to port everything from >>>> Akka >>>> > >> releases as they become available under the Apache license. I would >>>> > >> prefer to concentrate on bug fixes and test coverage. Enhancements >>>> if >>>> > >> people want them but I don't think we should grab them without >>>> > >> evidence they are wanted by Pekko users. >>>> > >> >>>> > >> Once Pekko 2.0.0 is out, I don't think we should continue to take >>>> Akka >>>> > >> changes over to 1.x unless they fix critical bugs - that they >>>> should >>>> > >> only go into 2.x in normal circumstances. >>>> > >> >>>> > >> There is a reasonable chance that Akka 2.8.0 changes will become >>>> > >> Apache licensed before we get to release Pekko 2.0.0. But maybe, it >>>> > >> might focus our minds to get 2.0.0 complete before then. We could >>>> then >>>> > >> just add Akka 2.8.0 stuff in a Pekko 2.x release. >>>> > >> >>>> > >> On Sat, 8 Nov 2025 at 20:08, kerr <[email protected]> wrote: >>>> > >> > >>>> > >> > I see, but if we want to support 1.4.0, then we will have much >>>> to port, >>>> > >> eg, >>>> > >> > Akka 2.8.0 needs to be ported to Pekko 1.4.x too . >>>> > >> > And we don't have the same setup, eg, sortImports, Scala >>>> versions, Java >>>> > >> > formatter, and Scala formatter, etc., which causes cherry >>>> picking a huge >>>> > >> > burden. >>>> > >> > While porting recently, I had to do many manual sortings to make >>>> the >>>> > >> code >>>> > >> > work with 1.3.x >>>> > >> > >>>> > >> > 何品 >>>> > >> > >>>> > >> > >>>> > >> > PJ Fanning <[email protected]> 于2025年11月9日周日 01:43写道： >>>> > >> > >>>> > >> > > 1.x releases will support Java 8. >>>> > >> > > I'm not going to guess what sort of 1.x releases we will need >>>> but we >>>> > >> > > will continue to do 1.x releases including some small >>>> enhancements >>>> > >> > > until 2.0.0 full release happens. After 2.0.0 is out, I think >>>> it is >>>> > >> > > fairly likely that we will only fix bugs in 1.x and this will >>>> likely >>>> > >> > > mean only occasional patch releases. >>>> > >> > > We could easily end up with 1.3.1 or 1.4.0 releases and >>>> possibly >>>> > >> beyond. >>>> > >> > > >>>> > >> > > On Sat, 8 Nov 2025 at 14:37, kerr <[email protected]> wrote: >>>> > >> > > > >>>> > >> > > > Is Pekko 1.3.0 the last release that we plan to support Java >>>> 8? >>>> > >> > > >>>> > >> > > >>>> --------------------------------------------------------------------- >>>> > >> > > 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] >>>> > >> >>>> > >> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>>
