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
