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
