How about we get a 1.2.0 out and then start 2.0.x? 1.2.x for Java 8 2.0.x for Java 8 + removing deprecated things?
何品 Nicolas Vollmar <nvoll...@gmail.com> 于2025年1月6日周一 21:41写道： > We could follow the same pattern. > Pekko 1.1 will remain on JDK 1.8 with important bug fixes ported back, and > Pekko 2.0 will move forward to JDK 11. > > On Mon, 6 Jan 2025 at 13:48, Matthew de Detrich <mdedetr...@gmail.com> > wrote: > > > > 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 > > > > >
