And for Aeron, I remember @johannes.rudo...@gmail.com was suggested to drop the UDP one, then Aeron would not be needed. 何品
kerr <hepin1...@gmail.com> 于2024年12月28日周六 21:45写道： > +1 for 2.0.0 > PJFanning, I have upgraded all my systems to JDK 21, but many others are > still using JDK 11, maybe we should just start with minimal JDK 11 required > instead of Java 17? > > > 何品 > > > PJ Fanning <fannin...@apache.org> 于2024年12月28日周六 21:31写道： > >> Continues >> https://lists.apache.org/thread/o1x9x325s57czwngb4so8pmzbxt0k6nv >> >> My view at the moment: >> * that we should rename from 1.2.0 to 2.0.0 because this allows us to >> avoid repeated discussions about semver and allows us wide discretion >> to remove deprecated code and unused code >> * I still think that we want to maintain as much compatibility (source >> and binary) with Pekko 1.x.y as possible >> * we should go to Java 17 minimum. Aeron, one of our most important >> dependencies, has gone to Java 17 minimum. Spring is another lib that >> is Java 17 only. Jackson 3 will be Java 17 only. >> * we might need to start with Java 11 in dev because I think we could >> have issues with doc generation or elsewhere due to tooling that >> doesn't yet support Java 17 >> * we should drop active Scala 2.12 support because of Scala 2.13.15 >> usage warnings and Scala 3.4+ have moved to a position that makes >> Scala 2.12 support increasingly hard to keep >> * we continue to make important fixes to Pekko 1.1 and less frequently >> to Pekko 1.0 so that users stuck with old Java versions or Scala 2.12 >> can stick with Pekko 1.x.y but be assured that fixes will be made >> >> On Sun, 1 Dec 2024 at 10:15, kerr <hepin1...@gmail.com> wrote: >> > >> > I tried it locally in the recent PR, which upgraded to 2.13.15. Now, we >> > need three configurations for all the cross-scala versions. >> > It seems like Drop 2.12 and Java 8 are good options now. >> > >> > I think there will be 100+ files that need to be changed. >> > And because Scala 3.3.4 doesn't match the 2.13.15, I think we can't >> make it >> > both works at the same time. >> > >> > 何品 >> > >> > >> > Matthew de Detrich <mdedetr...@gmail.com> 于2024年10月22日周二 16:06写道： >> > >> > > > I would really like to avoid having to maintain several branches. >> > > >> > > I don't think there is a way around this if we want to respect users' >> > > requirements and/or follow SemVer. Maintaining multiple branches is >> also >> > > the norm when it comes to maintenance for non trivial sized projects >> and as >> > > long as the projects are mainly source/feature compatible its not >> that much >> > > more maintenance work, basically whenever a PR gets merged into 2.x.x >> we >> > > will also cherry pick it in 1.x.x. >> > > >> > > That being said, we should pick an optimal time to do this i.e. when >> the >> > > sbt build and other such features stabilizes for Pekko. I want to also >> > > integrate some formatting rules into Pekko but I am waiting for a new >> > > release of scalafmt, but basically we want to make sure as much as >> possible >> > > that the build/formatting etc ete are "stable" and so most/all code >> drops >> > > are just bug fixes/new features >> > > >> > > > So, I really hope that we can start doing 1.2 or 2.0 releases for >> some of >> > > the modules soon. We already have some PRs that would ideally not >> appear in >> > > a 1.1 release (new features, small API changes, dependencies upgrades >> that >> > > break java 8 compat, etc.). >> > > >> > > Since we happen to be following strict semver, if we are going to do >> this >> > > then it would need to be a v2.0. There are advantages to doing a 2 >> release >> > > as since its a breaking release we can add features, i.e. >> > > >> > > * The inlining work for Scala 3 specifically (we had to roll this >> back in >> > > Pekko 1.x because we accidentally broke bin compatibility and there >> was no >> > > way around it) >> > > * Remove all deprecated methods, this should really help with >> > > maintenance burden >> > > * Undo the @noinline changes specifically wrt to tracing/telemetry >> (we can >> > > classify this as a breaking change) but also open up an official API >> with >> > > opentelemetry/kamon >> > > * Drop Java 8 support and have Java 11 as min >> > > * Use Scala 3.6 LTS???? (really emphasize the ? here, I don't even >> know if >> > > its a good idea but Scala 3 has solved a few issues in the next LTS >> that >> > > was unsolvable in Scala 3.3 LTS series) >> > > * Drop all akka <-> pekko migration features >> > > * Upgrade to sbt 2.x for the build (this is coming out soon). >> > > >> > > The downside to this is that we need to maintain 2 branches and so do >> all >> > > community plugins, but the pro's are also quite strong. We >> essentially can >> > > reset from a clean slate and we only need to make sure that Pekko >> Cluster >> > > upgrades work from 1.x to 2.x. Also if we plan to do this, release >> pekko >> > > 2.x will take a bit longer but I think its worth it (there is no real >> rush >> > > and if we are going to make a breaking version release we may as well >> do it >> > > properly). >> > > >> > > >> > > >> > > On Wed, Oct 16, 2024 at 5:21 PM PJ Fanning <fannin...@apache.org> >> wrote: >> > > >> > > > I don't think we can support keeping all the version numbers in sync >> > > > across all the Pekko modules. Pekko 1.1 is an exception because >> > > > * we needed to roll out the Scala 2 inlining across all the modules >> > > > * all our Pekko 1.0 modules are suffering from old dependencies due >> to >> > > our >> > > > decision to try to keep Pekko 1.0 dependencies as close as possible >> to >> > > the >> > > > last Akka Apache licensed releases to ease the switchover for Akka >> users >> > > - >> > > > and Pekko 1.1 modules have a much newer set of dependencies >> > > > >> > > > We can provide a doc page that lists our various modules and what >> > > versions >> > > > of other modules that they need. Also: as a place to keep track of >> the >> > > > latest release numbers. >> > > > >> > > > I have a BOM project but that is of limited use because with sbt >> you need >> > > > a plugin and some scripting to support BOMs. >> > > > https://github.com/pjfanning/pekko-libraries-bom >> > > > >> > > > So, I really hope that we can start doing 1.2 or 2.0 releases for >> some of >> > > > the modules soon. We already have some PRs that would ideally not >> appear >> > > in >> > > > a 1.1 release (new features, small API changes, dependencies >> upgrades >> > > that >> > > > break java 8 compat, etc.). >> > > > >> > > > I don't mind if we only remove Java 8 support in a few places. Pekko >> > > > Connectors could become a mess though - with some connectors >> needing Java >> > > > 11 or 17 minimum while others still support Java 8. Anything Slick >> > > related >> > > > will need Java 11 as HikariCP has driven them to now target Java 11. >> > > > >> > > > >> > > > On 2024/10/14 10:33:26 Arnout Engelen wrote: >> > > > > I would really like to avoid having to maintain several branches. >> > > > > >> > > > > I'd be in favour of dropping Java 8 support, but if that means we >> feel >> > > > > pressure to maintain several branches, I'd rather merely >> officially >> > > > > deprecate it. I feel similarly about Scala 2.12. Perhaps we can >> indeed >> > > > > start by requiring a higher Java version in satellite projects, >> like >> > > > > pekko-persistence-jdbc or pekko-connectors? >> > > > > >> > > > > I'm OK with dropping methods that were deprecated in Pekko 1.1.0 >> in >> > > > > the next major/minor version. We can do that whether or not we go >> with >> > > > > 1.2.0 or 2.0.0 for the version number if we follow >> > > > > >> > > > >> > > >> https://pekko.apache.org/docs/pekko/current/common/binary-compatibility-rules.html >> > > > > rather than 'strict semver'. >> > > > > >> > > > > We should decide on how synchronized version numbers across core >> and >> > > > > satellite projects are. Ideally it should be easy to find out >> which >> > > > > versions are compatible with each other. On the other hand, we >> should >> > > > > be careful not to introduce too much churn on the maintainer side. >> > > > > >> > > > > If we release version 2.0.0 of pekko-management, that could still >> > > > > depend on pekko-core 1.1.0, I think, right? But because there may >> be >> > > > > breaking changes between pekko-core 1.x and 2.x, once we release >> > > > > pekko-core 2.0.0, we should also release new major versions of all >> > > > > satellite projects (i.e. 3.0.0 for pekko-management). So the >> invariant >> > > > > is: "you must use a matching major version across transitive >> > > > > dependencies, but you may upgrade to newer minor/patch versions of >> > > > > transitive dependencies". >> > > > > >> > > > > This might be a reason to be sparse with major version updates, >> and at >> > > > > least go with 1.2.0 for the next pekko-core version: this would >> save >> > > > > us from having to do another round of releases of all satellite >> > > > > projects that just bump versions. >> > > > > >> > > > > >> > > > > Kind regards, >> > > > > >> > > > > Arnout >> > > > > >> > > > > On Fri, Aug 16, 2024 at 5:47 PM PJ Fanning <fannin...@apache.org> >> > > wrote: >> > > > > > >> > > > > > We have another discussion open about doing a Pekko 1.1.0 >> release. >> > > > > > >> > > > > > After we get that released, we will have to do 1.1.0 releases >> for >> > > > > > other other Pekko modules (HTTP, gRPC, Connectors, etc.). >> > > > > > >> > > > > > At the same time, we would need to decide on what to do about >> the >> > > next >> > > > > > release after that. >> > > > > > >> > > > > > I would suggest that we should consider making that next >> release a >> > > > > > 2.0.0 release - one where we get to remove some deprecated code >> and >> > > > > > potentially update the minimum Java and Scala versions that we >> > > > > > support. >> > > > > > We will continue to do patch releases for Pekko 1.0.x and Pekko >> 1.1.x >> > > > > > so users who are affected by us dropping some things are not >> going to >> > > > > > be too badly affected. >> > > > > > >> > > > > > * Drop Scala 2.12 support? The Scala 2.12 compiler has some type >> > > > > > inference issues that complicate our code. The next Scala 3 LTS >> > > > > > version looks like it will have some changes that will make it >> more >> > > > > > different from Scala 2.12. >> > > > > > * Go to Java 11 or even 17 as a minimum Java version? We >> already have >> > > > > > issues in Pekko Connectors where we are stuck on older >> dependency >> > > > > > versions because those dependencies have moved on from Java 8. >> > > > > > * Drop the methods and classes that were deprecated in Akka >> before we >> > > > > > split out Pekko? >> > > > > > * Possibly remove some of the methods and classes that we >> deprecated >> > > > in Pekko 1? >> > > > > > >> > > > > > What does everyone think? >> > > > > > >> > > > > > >> --------------------------------------------------------------------- >> > > > > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org >> > > > > > For additional commands, e-mail: dev-h...@pekko.apache.org >> > > > > > >> > > > > >> > > > > >> > > > > -- >> > > > > Arnout Engelen >> > > > > ASF Security Response >> > > > > Apache Pekko PMC member, ASF Member >> > > > > NixOS Committer >> > > > > Independent Open Source consultant >> > > > > >> > > > > >> --------------------------------------------------------------------- >> > > > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org >> > > > > For additional commands, e-mail: dev-h...@pekko.apache.org >> > > > > >> > > > > >> > > > >> > > > >> --------------------------------------------------------------------- >> > > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org >> > > > For additional commands, e-mail: dev-h...@pekko.apache.org >> > > > >> > > > >> > > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org >> For additional commands, e-mail: dev-h...@pekko.apache.org >> >>
