> So how about we remove deprecated methods since 1.1.0 / pre akka in 1.2.x ?
This is not allowed under semver, deprecated methods can only be removed in 2.x.x > And move to Java 11 once Netty or Scala requires Java 11? This will also likely not happen for some time, Scala is likely going to stick to using JDK 1.8 (moreso with Scala 2.x series) One thing we can do is to do a milestone release of 2.0.x to get an idea of how pressing it is with regards to users needing the later dependencies that aren't built on JDK 1.8. As you have mentioned with > https://github.com/ben-manes/caffeine is maintaining Java 8 with 2.9.x and > Java 11 with 3.1.x Due to how prevalent JDK 1.8 still is, most widely used libraries will still maintain a version of the library that is built against JDK 1.8 even if its not the latest version epic/minor version of the library. On Sun, Jan 5, 2025 at 5:27 PM kerr <hepin1...@gmail.com> wrote: > > At least Netty 4.2 just moved to Java 8 . > So how about we remove deprecated methods since 1.1.0 / pre akka in 1.2.x ? > And move to Java 11 once Netty or Scala requires Java 11? > > https://github.com/ben-manes/caffeine is maintaining Java 8 with 2.9.x and > Java 11 with 3.1.x > > 何品 > > > Matthew de Detrich <mdedetr...@gmail.com> 于2025年1月5日周日 22:47写道： > > > > This of mine > > > > This opinion of mine* > > > > On Sun, Jan 5, 2025 at 3:46 PM Matthew de Detrich <mdedetr...@gmail.com> > > wrote: > > > > > > My opinion from > > > https://lists.apache.org/thread/tky5by9yfpyft52q0rhzzbbsdjp8vo95 > > > hasn't really changed. As stated in > > > https://lists.apache.org/thread/fv3rff6fpy01k2cq3rgl5zypxzh17223, the > > > most critical element is really how disruptive a 2.x.x release is to > > > the plugin/library ecosystem around Pekko. If we do this, every single > > > library/plugin for Pekko will be forced to maintain 2 branches, one > > > against Pekko 1.x.x and another against Pekko 2.x.x. > > > > > > This of mine can sway depending on proper feedback from users, i.e. > > > getting a gauge as to how many people are still reliant on JDK 1.8 > > > amongst the other listed points. Also I know that I am aware that we > > > have some dependencies we cannot update due to those dependencies not > > > supporting JDK 1.8 but in reality how critical is this? Specifically > > > its a big difference if those dependencies still maintain patch > > > release for the version branch that supports JDK 1.8 vs not. > > > > > > On Sat, Dec 28, 2024 at 2:48 PM kerr <hepin1...@gmail.com> wrote: > > > > > > > > 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 > > > > >> > > > > >> > > > > --------------------------------------------------------------------- > > 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
