> 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 > >
