You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pekko.apache.org by PJ Fanning <fa...@apache.org> on 2024/08/16 15:47:06 UTC
[DISCUSS] forward dev after we release Pekko 1.1.0
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-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: [DISCUSS] forward dev after we release Pekko 1.1.0
Posted by kerr <he...@gmail.com>.
As pjf said, we can't add features to 1.1.x anymore, so that's why 1.2.x
outcome, it will accumulate some features we added after 1.1.0
My free time is really limited, so don't expect many features in 1.2.x :).
I would like to have more stream operators, which will make pekko-stream a
drop in replace of rxJava/reactor-core/zio-stream/fs2
何品
Nicolas Vollmar <nv...@gmail.com> 于2025年1月10日周五 22:54写道：
> I agree with moving forward to Java 11 / dropping Scala 2.12 for 2.0
>
> My question would be: what would 1.2 then contain/try to achieve what we
> can't with 1.1 before moving to 2.0?
>
> On Fri, 10 Jan 2025 at 15:20, kerr <he...@gmail.com> wrote:
>
>> When working on https://github.com/apache/pekko/pull/1702 I found Scala
>> 2.12.x is very annoying.
>>
>> I suggest that we have a 1.2.x and then move to 2.0.x
>>
>> Where:
>> 1.2.x: java 8 + 2.12.x supported.
>> 2.0.x: Java 11 required, 2.12.x dropped.
>>
>> Maintaining 2.12.x is a wast of time , at least for me.
>>
>
Re: [DISCUSS] forward dev after we release Pekko 1.1.0
Posted by Nicolas Vollmar <nv...@gmail.com>.
I agree with moving forward to Java 11 / dropping Scala 2.12 for 2.0
My question would be: what would 1.2 then contain/try to achieve what we
can't with 1.1 before moving to 2.0?
On Fri, 10 Jan 2025 at 15:20, kerr <he...@gmail.com> wrote:
> When working on https://github.com/apache/pekko/pull/1702 I found Scala
> 2.12.x is very annoying.
>
> I suggest that we have a 1.2.x and then move to 2.0.x
>
> Where:
> 1.2.x: java 8 + 2.12.x supported.
> 2.0.x: Java 11 required, 2.12.x dropped.
>
> Maintaining 2.12.x is a wast of time , at least for me.
>
Re: [DISCUSS] forward dev after we release Pekko 1.1.0
Posted by kerr <he...@gmail.com>.
When working on https://github.com/apache/pekko/pull/1702 I found Scala
2.12.x is very annoying.
I suggest that we have a 1.2.x and then move to 2.0.x
Where:
1.2.x: java 8 + 2.12.x supported.
2.0.x: Java 11 required, 2.12.x dropped.
Maintaining 2.12.x is a wast of time , at least for me.
Re: [DISCUSS] forward dev after we release Pekko 1.1.0
Posted by kerr <he...@gmail.com>.
At least I'm OK with Java 11, Those who want Java 8 can help maintain the
1.1.x or 1.2.x branch.
As we are volunteers not selling the support for Java 1.8.
Akka/Lightbend have move to Java 11 too.
Re: [DISCUSS] forward dev after we release Pekko 1.1.0
Posted by kerr <he...@gmail.com>.
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 <nv...@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 <md...@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 <he...@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 <md...@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 <
> > mdedetrich@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 <he...@gmail.com> wrote:
> > > > > >
> > > > > > And for Aeron, I remember @johannes.rudolph@gmail.com was
> > suggested
> > > > to drop
> > > > > > the UDP one, then Aeron would not be needed.
> > > > > > 何品
> > > > > >
> > > > > >
> > > > > > kerr <he...@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 <fa...@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 <he...@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 <md...@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 <
> > > > fanningpj@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 <
> > > > fanningpj@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-unsubscribe@pekko.apache.org
> > > > > > >> > > > > > For additional commands, e-mail:
> > > > dev-help@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-unsubscribe@pekko.apache.org
> > > > > > >> > > > > For additional commands, e-mail:
> > dev-help@pekko.apache.org
> > > > > > >> > > > >
> > > > > > >> > > > >
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >>
> > > > ---------------------------------------------------------------------
> > > > > > >> > > > To unsubscribe, e-mail:
> dev-unsubscribe@pekko.apache.org
> > > > > > >> > > > For additional commands, e-mail:
> > dev-help@pekko.apache.org
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >>
> > > > > > >>
> > > > ---------------------------------------------------------------------
> > > > > > >> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > >> For additional commands, e-mail: dev-help@pekko.apache.org
> > > > > > >>
> > > > > > >>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > For additional commands, e-mail: dev-help@pekko.apache.org
> >
> >
>
Re: [DISCUSS] forward dev after we release Pekko 1.1.0
Posted by Nicolas Vollmar <nv...@gmail.com>.
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 <md...@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 <he...@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 <md...@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 <
> mdedetrich@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 <he...@gmail.com> wrote:
> > > > >
> > > > > And for Aeron, I remember @johannes.rudolph@gmail.com was
> suggested
> > > to drop
> > > > > the UDP one, then Aeron would not be needed.
> > > > > 何品
> > > > >
> > > > >
> > > > > kerr <he...@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 <fa...@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 <he...@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 <md...@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 <
> > > fanningpj@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 <
> > > fanningpj@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-unsubscribe@pekko.apache.org
> > > > > >> > > > > > For additional commands, e-mail:
> > > dev-help@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-unsubscribe@pekko.apache.org
> > > > > >> > > > > For additional commands, e-mail:
> dev-help@pekko.apache.org
> > > > > >> > > > >
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > > >
> > > > > >>
> > > ---------------------------------------------------------------------
> > > > > >> > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > >> > > > For additional commands, e-mail:
> dev-help@pekko.apache.org
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >>
> > > > > >>
> > > ---------------------------------------------------------------------
> > > > > >> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > >> For additional commands, e-mail: dev-help@pekko.apache.org
> > > > > >>
> > > > > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > For additional commands, e-mail: dev-help@pekko.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>
Re: [DISCUSS] forward dev after we release Pekko 1.1.0
Posted by Matthew de Detrich <md...@gmail.com>.
> 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 <he...@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 <md...@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 <md...@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 <he...@gmail.com> wrote:
> > > >
> > > > And for Aeron, I remember @johannes.rudolph@gmail.com was suggested
> > to drop
> > > > the UDP one, then Aeron would not be needed.
> > > > 何品
> > > >
> > > >
> > > > kerr <he...@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 <fa...@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 <he...@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 <md...@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 <
> > fanningpj@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 <
> > fanningpj@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-unsubscribe@pekko.apache.org
> > > > >> > > > > > For additional commands, e-mail:
> > dev-help@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-unsubscribe@pekko.apache.org
> > > > >> > > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > > >> > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > > >
> > > > >>
> > ---------------------------------------------------------------------
> > > > >> > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > >> > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > > >> > > >
> > > > >> > > >
> > > > >> > >
> > > > >>
> > > > >>
> > ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > >> For additional commands, e-mail: dev-help@pekko.apache.org
> > > > >>
> > > > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > For additional commands, e-mail: dev-help@pekko.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: [DISCUSS] forward dev after we release Pekko 1.1.0
Posted by kerr <he...@gmail.com>.
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 <md...@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 <md...@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 <he...@gmail.com> wrote:
> > >
> > > And for Aeron, I remember @johannes.rudolph@gmail.com was suggested
> to drop
> > > the UDP one, then Aeron would not be needed.
> > > 何品
> > >
> > >
> > > kerr <he...@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 <fa...@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 <he...@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 <md...@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 <
> fanningpj@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 <
> fanningpj@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-unsubscribe@pekko.apache.org
> > > >> > > > > > For additional commands, e-mail:
> dev-help@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-unsubscribe@pekko.apache.org
> > > >> > > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > >> > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > > >
> > > >>
> ---------------------------------------------------------------------
> > > >> > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > >> > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > >> For additional commands, e-mail: dev-help@pekko.apache.org
> > > >>
> > > >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>
Re: [DISCUSS] forward dev after we release Pekko 1.1.0
Posted by Matthew de Detrich <md...@gmail.com>.
> This of mine
This opinion of mine*
On Sun, Jan 5, 2025 at 3:46 PM Matthew de Detrich <md...@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 <he...@gmail.com> wrote:
> >
> > And for Aeron, I remember @johannes.rudolph@gmail.com was suggested to drop
> > the UDP one, then Aeron would not be needed.
> > 何品
> >
> >
> > kerr <he...@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 <fa...@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 <he...@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 <md...@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 <fa...@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 <fa...@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-unsubscribe@pekko.apache.org
> > >> > > > > > For additional commands, e-mail: dev-help@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-unsubscribe@pekko.apache.org
> > >> > > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > >> > > > >
> > >> > > > >
> > >> > > >
> > >> > > >
> > >> ---------------------------------------------------------------------
> > >> > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > >> > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > >> > > >
> > >> > > >
> > >> > >
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > >> For additional commands, e-mail: dev-help@pekko.apache.org
> > >>
> > >>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: [DISCUSS] forward dev after we release Pekko 1.1.0
Posted by Matthew de Detrich <md...@gmail.com>.
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 <he...@gmail.com> wrote:
>
> And for Aeron, I remember @johannes.rudolph@gmail.com was suggested to drop
> the UDP one, then Aeron would not be needed.
> 何品
>
>
> kerr <he...@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 <fa...@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 <he...@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 <md...@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 <fa...@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 <fa...@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-unsubscribe@pekko.apache.org
> >> > > > > > For additional commands, e-mail: dev-help@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-unsubscribe@pekko.apache.org
> >> > > > > For additional commands, e-mail: dev-help@pekko.apache.org
> >> > > > >
> >> > > > >
> >> > > >
> >> > > >
> >> ---------------------------------------------------------------------
> >> > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> >> > > > For additional commands, e-mail: dev-help@pekko.apache.org
> >> > > >
> >> > > >
> >> > >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> >> For additional commands, e-mail: dev-help@pekko.apache.org
> >>
> >>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: [DISCUSS] forward dev after we release Pekko 1.1.0
Posted by kerr <he...@gmail.com>.
And for Aeron, I remember @johannes.rudolph@gmail.com was suggested to drop
the UDP one, then Aeron would not be needed.
何品
kerr <he...@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 <fa...@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 <he...@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 <md...@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 <fa...@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 <fa...@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-unsubscribe@pekko.apache.org
>> > > > > > For additional commands, e-mail: dev-help@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-unsubscribe@pekko.apache.org
>> > > > > For additional commands, e-mail: dev-help@pekko.apache.org
>> > > > >
>> > > > >
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
>> > > > For additional commands, e-mail: dev-help@pekko.apache.org
>> > > >
>> > > >
>> > >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
>> For additional commands, e-mail: dev-help@pekko.apache.org
>>
>>
Re: [DISCUSS] forward dev after we release Pekko 1.1.0
Posted by kerr <he...@gmail.com>.
+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 <fa...@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 <he...@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 <md...@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 <fa...@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 <fa...@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-unsubscribe@pekko.apache.org
> > > > > > For additional commands, e-mail: dev-help@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-unsubscribe@pekko.apache.org
> > > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > >
> > > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>
Re: [DISCUSS] forward dev after we release Pekko 1.1.0
Posted by PJ Fanning <fa...@apache.org>.
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 <he...@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 <md...@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 <fa...@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 <fa...@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-unsubscribe@pekko.apache.org
> > > > > For additional commands, e-mail: dev-help@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-unsubscribe@pekko.apache.org
> > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > For additional commands, e-mail: dev-help@pekko.apache.org
> > >
> > >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: [DISCUSS] forward dev after we release Pekko 1.1.0
Posted by kerr <he...@gmail.com>.
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 <md...@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 <fa...@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 <fa...@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-unsubscribe@pekko.apache.org
> > > > For additional commands, e-mail: dev-help@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-unsubscribe@pekko.apache.org
> > > For additional commands, e-mail: dev-help@pekko.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > For additional commands, e-mail: dev-help@pekko.apache.org
> >
> >
>
Re: [DISCUSS] forward dev after we release Pekko 1.1.0
Posted by Matthew de Detrich <md...@gmail.com>.
> 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 <fa...@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 <fa...@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-unsubscribe@pekko.apache.org
> > > For additional commands, e-mail: dev-help@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-unsubscribe@pekko.apache.org
> > For additional commands, e-mail: dev-help@pekko.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>
Re: [DISCUSS] forward dev after we release Pekko 1.1.0
Posted by PJ Fanning <fa...@apache.org>.
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 <fa...@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-unsubscribe@pekko.apache.org
> > For additional commands, e-mail: dev-help@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-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: [DISCUSS] forward dev after we release Pekko 1.1.0
Posted by Arnout Engelen <en...@apache.org>.
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 <fa...@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-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: [DISCUSS] forward dev after we release Pekko 1.1.0
Posted by Matthew de Detrich <md...@gmail.com>.
wrt Scala 2.12, I agree. Regarding Java 8, this is technically a breaking
change so we would need to increase the version to 2.0.x which isn't a big
deal, but we may need to maintain 2 branches as 1.1.x+ would still likely
be supported for some time (and we still have users that need Java 8
support).
On Mon, Oct 7, 2024 at 3:20 PM PJ Fanning <fa...@apache.org> wrote:
> We are running into an increasing number of Java libs that we rely on that
> don't support Java 8.
>
> Can I suggest that we cut v1.1.x branches on some of our worst affected
> modules and raise the minimum Java version on the main branches to Java 17.
> Most of the libs that affect us still support Java 11 but there are a few
> like Aeron and Spring where the latest versions need Java 17.
>
> The modules where I think we should start are:
> * pekko-persistence-jdbc
> * pekko-connectors (after we do the 1.1.0 release which should be soon)
>
> Can I suggest that we call the next releases on these modules where we
> drop Java 8 support version 2.0.0?
>
> Regarding dropping Scala 2.12 support - I think we shouldn't. After
> checking the download stats for our jars, Scala 2.12 remains popular - way
> more popular for Pekko users than Scala 3. I'll go with the flow, if people
> actually think we should drop Scala 2.12 for the dev version of Pekko.
> There is an argument to say that Scala 2.12 users can stick with Pekko 1.1
> or 1.0. We will continue to do bug fixes and critical dependency updates
> for our legacy release lines.
>
> I also think that we should drop some of the connectors in the forward dev
> version of Pekko Connectors (future Pekko Connectors v1.2.0 or v2.0.0
> release). We no longer properly test some of the connectors because the
> Docker setups are broken. We can always bring back abandoned Connectors if
> we find some volunteers to help maintain them.
>
>
> On 2024/08/16 15:47:06 PJ Fanning 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-unsubscribe@pekko.apache.org
> > For additional commands, e-mail: dev-help@pekko.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>
Re: [DISCUSS] forward dev after we release Pekko 1.1.0
Posted by PJ Fanning <fa...@apache.org>.
We are running into an increasing number of Java libs that we rely on that don't support Java 8.
Can I suggest that we cut v1.1.x branches on some of our worst affected modules and raise the minimum Java version on the main branches to Java 17. Most of the libs that affect us still support Java 11 but there are a few like Aeron and Spring where the latest versions need Java 17.
The modules where I think we should start are:
* pekko-persistence-jdbc
* pekko-connectors (after we do the 1.1.0 release which should be soon)
Can I suggest that we call the next releases on these modules where we drop Java 8 support version 2.0.0?
Regarding dropping Scala 2.12 support - I think we shouldn't. After checking the download stats for our jars, Scala 2.12 remains popular - way more popular for Pekko users than Scala 3. I'll go with the flow, if people actually think we should drop Scala 2.12 for the dev version of Pekko. There is an argument to say that Scala 2.12 users can stick with Pekko 1.1 or 1.0. We will continue to do bug fixes and critical dependency updates for our legacy release lines.
I also think that we should drop some of the connectors in the forward dev version of Pekko Connectors (future Pekko Connectors v1.2.0 or v2.0.0 release). We no longer properly test some of the connectors because the Docker setups are broken. We can always bring back abandoned Connectors if we find some volunteers to help maintain them.
On 2024/08/16 15:47:06 PJ Fanning 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-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org