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 2023/11/05 11:12:49 UTC
having non-LTS releases
The core pekko repo [1] has quite a few changes in its main branch that are are targeted at a future 1.1.0 release.
We haven't really agreed on what to do with the code that was already deprecated in the Akka era and there is also the issue of the ApiMayChange annotations on some of the APIs.
There are also some new features that developers want to add.
We don't have a great deal of developer effort available to us.
I suspect that we need to need to balance the need to release some of the 1.1 changes and then maybe try to make another batch of changes in Pekko 1.2.
What if we aimed to do a Pekko 1.1.0 release in a few months and said that it was not a Long Term Support release? If we go down this line, we would probably want to have a tentative plan as to when a new LTS release would happen.
An example of something that would be useful to release would be the netty4 support. I know that the Apache Flink team would like to use this.
Alternatively, we could do a Pekko 1.1.0-M1 release. I suspect that we would end up with a fair number of these and the M version number would discourage uptake (except for testing).
What are people's thoughts on the options?
[1] https://github.com/apache/incubator-pekko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: having non-LTS releases
Posted by Matthew de Detrich <ma...@aiven.io.INVALID>.
> I would like to add https://github.com/apache/incubator-pekko/pull/765 to
the M1. I think it would be good to get the changes tested.
Yes this is part of the migration of akka to pekko cluster changes I
mentioned earlier.
We also need to make a decision on whether these changes should only land
in 1.0.x
or 1.0.x and 1.1.x.
On Thu, Jan 11, 2024 at 5:10 AM PJ Fanning <fa...@apache.org> wrote:
> I would like to add https://github.com/apache/incubator-pekko/pull/765 to
> the M1. I think it would be good to get the changes tested.
>
> On Wed 10 Jan 2024, 01:07 Matthew de Detrich,
> <ma...@aiven.io.invalid> wrote:
>
> > So I have some good news for one of the big ticket items listed earlier,
> > Pekko is now using the latest version of sbt-osgi which contains a lot of
> > fixes and
> > improvements, see https://github.com/apache/incubator-pekko/pull/920.
> This
> > avoids
> > us having to drop sbt-osgi support (doing so is not off the table
> > completely but should
> > be made as a community decision later). Also
> > https://github.com/apache/incubator-pekko/pull/252
> > landed which is important since it's a behavioural change.
> >
> > I would say the only other big item that should be handled before an M1
> > vote is
> > finishing off the inliner changes,
> > https://github.com/apache/incubator-pekko/pull/587
> > and the migration of akka to pekko clusters. A milestone release of these
> > changes
> > will provide ample opportunity for extensive testing to make sure as much
> > as possible
> > that the full release is without issues. I left out multi-release-jar
> > support, my feeling is
> > that this is too big of a change for M1 but It might make sense as an M2
> > or as part of 1.2.x.
> >
> > If there is anything that's left out please mention it.
> >
> > On Sun, Dec 24, 2023 at 7:42 AM kerr <he...@gmail.com> wrote:
> >
> > > +1 for this, IIRC Matthew suggested this kind of release too.
> > > 何品
> > >
> > >
> > > Matthew de Detrich <ma...@aiven.io.invalid> 于2023年12月13日周三
> > > 07:06写道：
> > >
> > > > Apologies for necroing this topic, but there is one other feature I
> > would
> > > > like to add to the M1
> > > > milestone release which is
> > > > https://github.com/apache/incubator-pekko/pull/252. The reason I
> > > > am pointing out this issue specifically is that it is a breaking
> > > behaviour
> > > > change (all of the
> > > > details are in the PR) so it needs to land for the 1.1.x series,
> > ideally
> > > > for M1 so we can figure
> > > > out if there are any behavioural regressions.
> > > >
> > > > On Mon, Nov 6, 2023 at 8:40 PM Matthew de Detrich <
> > > > matthew.dedetrich@aiven.io> wrote:
> > > >
> > > > > > Some of those changes will likely also need backporting for
> > > > > 1.0.x releases.
> > > > >
> > > > > Indeed, the rolling migration from Akka to Pekko clusters is
> > actually a
> > > > > feature for 1.0.x, but because
> > > > > of how its designed (i.e. there is a configuration for the
> > > > sender/receiver
> > > > > address), this feature and
> > > > > configuration also needs to exist for Pekko 1.1.0 otherwise the
> user
> > > > > experience will be extremely
> > > > > unintuitive.
> > > > >
> > > > > > I don't think a 1.1.0-M0 is warranted. This git tag has code that
> > is
> > > > > very similar to Pekko 1.0.1. I don't see the merit in having
> multiple
> > > > > ASF contributors having to review such a release.
> > > > >
> > > > > It trivializes MiMa management which is worth the annoyance of
> doing
> > a
> > > > > release. There really
> > > > > isn't any other way without breaking ASF policy, we basically have
> to
> > > > make
> > > > > a release that is
> > > > > not a "real" release.
> > > > >
> > > > > One thing to note is this doesn't occur that frequently (i.e. M0
> > > > > milestones), i.e. its only on a
> > > > > minor version bump and it can be argued that this release can be
> part
> > > of
> > > > > the formality of
> > > > > when we decide to make a 1.1.x branch, i.e. the community makes a
> > > > > decision/vote that
> > > > > at a certain point in time we are going to bump the minor version
> > which
> > > > > requires a vote
> > > > > and that some vote is also used for the M0 release.
> > > > >
> > > > > In fact, now that I think/write about it, we really should have a
> > > formal
> > > > > vote when we make a
> > > > > minor version bump because it is a significant change, it shouldn't
> > be
> > > > > done at whim (even
> > > > > if its from a PMC)
> > > > >
> > > > > > When I say LTS, I mean what versions will get patches for a long
> > > time.
> > > > > Java releases are a good example. If an org really needs a Java 22
> > > > > feature they can use Java 22 in production - but they are expected
> to
> > > > > upgrade to Java 23, etc. when those versions are released until a
> new
> > > > > Java LTS is released. There are other OSS equivalents. I am not
> > > > > talking about Commercial Support contracts - commercial entities
> are
> > > > > very welcome to fill this gap - this does not need to relate
> directly
> > > > > to the FOSS releases from the ASF project team.
> > > > >
> > > > > I understand the difference between LTS and commercial contract,
> it's
> > > > just
> > > > > that
> > > > > even the variables for how long the support is, is something that I
> > > don't
> > > > > think
> > > > > we have any ability to estimate concretely now. In summary, in my
> > view
> > > > > it's too
> > > > > soon to even be discussing this.
> > > > >
> > > > > > If the consensus is to delay Pekko 1.1 until every candidate
> change
> > > is
> > > > > made - then fine - but this stops users from using features that
> are
> > > > > ready to try, like the Netty 4 support.
> > > > >
> > > > > As discussed on the github issue[1], this is a non issue. A
> milestone
> > > > > release
> > > > > will cater to anyone who really needs netty4 and as stated, it's
> just
> > > as
> > > > > tested
> > > > > as any other Pekko release is. If people are really desperate for
> > > netty4,
> > > > > then
> > > > > they can use the milestone (I would also note that I haven't seen
> any
> > > > > indication that anyone is begging for netty4 right now).
> > > > >
> > > > > > Since Pekko 1.1.0 full release seems like a long way away, it
> might
> > > be
> > > > > worth considering mechanisms to release the most useful changes
> > > > > earlier - in a way that Pekko 1.0 users can uptake.
> > > > >
> > > > > This is what milestones are for, i.e. they are precisely the
> > mechanism
> > > > > to solve this issue. It also solves a host of other issues as
> > discussed
> > > > > here[2].
> > > > >
> > > > > [1] https://github.com/apache/incubator-pekko/pull/778
> > > > > [2]
> https://lists.apache.org/thread/o494q89hhg64r5nwv4rnq6fsx9zofmny
> > > > >
> > > > > On Sun, Nov 5, 2023 at 10:57 PM PJ Fanning <fa...@gmail.com>
> > > wrote:
> > > > >
> > > > >> I have no objections to the general list of changes that we need
> for
> > > > >> 1.1.0. Some of those changes will likely also need backporting for
> > > > >> 1.0.x releases.
> > > > >>
> > > > >> A 1.1.0-M1 release makes sense. I want to delay it by a week or 2
> > > > >> while we decide what to do about the config logging (recent Akka
> > CVE).
> > > > >>
> > > > >> I don't think a 1.1.0-M0 is warranted. This git tag has code that
> is
> > > > >> very similar to Pekko 1.0.1. I don't see the merit in having
> > multiple
> > > > >> ASF contributors having to review such a release.
> > > > >>
> > > > >> I guess it is a separate conversation but there is a fair degree
> of
> > > > >> resistance to us dropping support for anything. I think we will
> need
> > > > >> to only drop support if it really makes things much easier for us.
> > > > >> Multi Release Jars seems like a better option than dropping Java 8
> > > > >> support (for instance).
> > > > >>
> > > > >> When I say LTS, I mean what versions will get patches for a long
> > time.
> > > > >> Java releases are a good example. If an org really needs a Java 22
> > > > >> feature they can use Java 22 in production - but they are expected
> > to
> > > > >> upgrade to Java 23, etc. when those versions are released until a
> > new
> > > > >> Java LTS is released. There are other OSS equivalents. I am not
> > > > >> talking about Commercial Support contracts - commercial entities
> are
> > > > >> very welcome to fill this gap - this does not need to relate
> > directly
> > > > >> to the FOSS releases from the ASF project team.
> > > > >>
> > > > >> If the consensus is to delay Pekko 1.1 until every candidate
> change
> > is
> > > > >> made - then fine - but this stops users from using features that
> are
> > > > >> ready to try, like the Netty 4 support.
> > > > >>
> > > > >> Since Pekko 1.1.0 full release seems like a long way away, it
> might
> > be
> > > > >> worth considering mechanisms to release the most useful changes
> > > > >> earlier - in a way that Pekko 1.0 users can uptake.
> > > > >>
> > > > >>
> > > > >> On Sun, 5 Nov 2023 at 12:59, Matthew de Detrich
> > > > >> <ma...@aiven.io.invalid> wrote:
> > > > >> >
> > > > >> > So my take on this
> > > > >> >
> > > > >> > - We should do milestones to solve the general problem you are
> > > > alluding
> > > > >> to,
> > > > >> > i.e. the M1 milestone that you suggest that we vote on (we
> should
> > > also
> > > > >> do
> > > > >> > the M0 milestone which is at the exact moment when a new bump to
> > > minor
> > > > >> > version is done, reasoning why is given in this thread[1]). I
> > would
> > > > >> argue
> > > > >> > that doing an M1 now is a good idea and then an M2 once other
> > > critical
> > > > >> > features land (such as inliner which is mentioned in the below
> > > point)
> > > > >> > - There are some critical features that need to be merged
> before a
> > > > >> release
> > > > >> > of 1.1.0 Pekko Core is ever made (and 1.1.0 Pekko core needs to
> be
> > > > >> released
> > > > >> > before any other 1.1.0 releases for the other modules) due to
> > > > technical
> > > > >> > reasons. On the top of my head the critical features so far are
> > the
> > > > >> > inliner[2] and rolling update migration of Akka to Pekko
> > > clusters[3].
> > > > I
> > > > >> > think it's achievable to get [2] and [3] done in a few months
> > time,
> > > > but
> > > > >> we
> > > > >> > would have to focus on getting it over the line ([2] is already
> > > > "done",
> > > > >> it
> > > > >> > just needs a review and testing in downstream modules, [3]
> likely
> > > > needs
> > > > >> > more work and most of all testing so that it works as expected).
> > > > >> > - Regarding LTS, I don't think we should entertain the idea now.
> > We
> > > > >> have no
> > > > >> > idea of what and how an LTS can work and we don't even have the
> > > > capacity
> > > > >> > for it. It might even be a thing that LTS's are "someone else's"
> > > > problem
> > > > >> > (Pekko is open source after all). I think the most critical
> thing
> > is
> > > > >> > sticking to semantic versioning, such an expectation is
> manageable
> > > for
> > > > >> us
> > > > >> > and I would argue is kind of a requirement for large open source
> > > > >> projects
> > > > >> > like Pekko
> > > > >> > - Fixing the manager name [4] should also be fixed for 1.1.0
> > > (actually
> > > > >> if
> > > > >> > anything this should be fixed for 1.0.x branch as well)
> > > > >> > - As kind of a stretch goal, sbt-multi-release-jar support for
> > > > 1.1.0[5]
> > > > >> > would be awesome as it would unblock a **lot** of things while
> > also
> > > > >> keeping
> > > > >> > part of the community happy
> > > > >> > - Releasing pekko 1.1.0 with the latest sbt-osgi (which
> apparently
> > > > >> fixes a
> > > > >> > lot of pain points versus the current osgi used in Pekko 1.0.x)
> > > would
> > > > be
> > > > >> > another nice stretch goal, currently there is one issue with
> > > duplicate
> > > > >> > classes but we now have infrastructure set up[6] so that we can
> > > > properly
> > > > >> > test such changes.
> > > > >> >
> > > > >> > Note that a lot of the underlying reasoning behind my points are
> > > also
> > > > >> > strategic, i.e. keeping features which can be considered
> critical
> > to
> > > > >> Pekko
> > > > >> > and/or current Akka users which don't require to much effort
> > > > (basically
> > > > >> > anything that gives a reason for people to use/migrate to Pekko
> > > while
> > > > >> not
> > > > >> > breaking the i.e. our bank so to speak). I know that there has
> > been
> > > a
> > > > >> push
> > > > >> > to do things like drop JDK 8, Scala 2.12, osgi etc etc due to
> > death
> > > > by a
> > > > >> > thousand cuts but tbh objectively speaking these issues are not
> > > taking
> > > > >> up
> > > > >> > that much time (at least personally by far the largest amount of
> > > time
> > > > >> spent
> > > > >> > is just overhead of having to do so many releases and validate
> > them,
> > > > >> really
> > > > >> > looking forward to the day when we can automate everything with
> > > > >> > sbt-reproducible-builds/jardiff/create jars in ci etc etc).
> Pekko
> > > > 2.0.x
> > > > >> > series is when we can look forward to drop a lot of this
> "annoying
> > > > >> > maintenance" stuff and I would actually strongly argue that at
> the
> > > > time
> > > > >> > when we start looking at Pekko 2.0.x we actually get a better
> idea
> > > of
> > > > >> what
> > > > >> > our Pekko users look like, because as has been shown due to the
> > > chaos
> > > > >> > created from the license change very few us had any somewhat
> > > realistic
> > > > >> lens
> > > > >> > as to how the Pekko community (specifically users) look like,
> i.e.
> > > > while
> > > > >> > the OS would **LOVE** to get rid of JDK 1.8 support it just so
> > > happens
> > > > >> that
> > > > >> > a lot of people still need to use JDK 1.8 and even though there
> > are
> > > > >> reasons
> > > > >> > to move away from 1.8 evidently they aren't relevant.
> > > > >> >
> > > > >> > [1]
> > > https://lists.apache.org/thread/o494q89hhg64r5nwv4rnq6fsx9zofmny
> > > > >> > [2] https://github.com/apache/incubator-pekko/pull/305
> > > > >> > [3] https://github.com/apache/incubator-pekko/pull/765
> > > > >> > [4] https://github.com/apache/incubator-pekko/pull/587
> > > > >> > [5] https://github.com/sbt/sbt-multi-release-jar/issues/22
> > > > >> > [6] https://github.com/apache/incubator-pekko/issues/75
> > > > >> >
> > > > >> > On Sun, Nov 5, 2023 at 12:12 PM PJ Fanning <
> fanningpj@apache.org>
> > > > >> wrote:
> > > > >> >
> > > > >> > > The core pekko repo [1] has quite a few changes in its main
> > branch
> > > > >> that
> > > > >> > > are are targeted at a future 1.1.0 release.
> > > > >> > >
> > > > >> > > We haven't really agreed on what to do with the code that was
> > > > already
> > > > >> > > deprecated in the Akka era and there is also the issue of the
> > > > >> ApiMayChange
> > > > >> > > annotations on some of the APIs.
> > > > >> > >
> > > > >> > > There are also some new features that developers want to add.
> > > > >> > >
> > > > >> > > We don't have a great deal of developer effort available to
> us.
> > > > >> > >
> > > > >> > > I suspect that we need to need to balance the need to release
> > some
> > > > of
> > > > >> the
> > > > >> > > 1.1 changes and then maybe try to make another batch of
> changes
> > in
> > > > >> Pekko
> > > > >> > > 1.2.
> > > > >> > >
> > > > >> > > What if we aimed to do a Pekko 1.1.0 release in a few months
> and
> > > > said
> > > > >> that
> > > > >> > > it was not a Long Term Support release? If we go down this
> line,
> > > we
> > > > >> would
> > > > >> > > probably want to have a tentative plan as to when a new LTS
> > > release
> > > > >> would
> > > > >> > > happen.
> > > > >> > >
> > > > >> > > An example of something that would be useful to release would
> be
> > > the
> > > > >> > > netty4 support. I know that the Apache Flink team would like
> to
> > > use
> > > > >> this.
> > > > >> > >
> > > > >> > > Alternatively, we could do a Pekko 1.1.0-M1 release. I suspect
> > > that
> > > > we
> > > > >> > > would end up with a fair number of these and the M version
> > number
> > > > >> would
> > > > >> > > discourage uptake (except for testing).
> > > > >> > >
> > > > >> > > What are people's thoughts on the options?
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > > [1] https://github.com/apache/incubator-pekko
> > > > >> > >
> > > > >> > >
> > > > ---------------------------------------------------------------------
> > > > >> > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > >> > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >> > --
> > > > >> >
> > > > >> > Matthew de Detrich
> > > > >> >
> > > > >> > *Aiven Deutschland GmbH*
> > > > >> >
> > > > >> > Immanuelkirchstraße 26, 10405 Berlin
> > > > >> >
> > > > >> > Alexanderufer 3-7, 10117 Berlin
> > > > >> >
> > > > >> > Amtsgericht Charlottenburg, HRB 209739 B
> > > > >> >
> > > > >> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > > > >> >
> > > > >> > *m:* +491603708037
> > > > >> >
> > > > >> > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> > > > >>
> > > > >>
> > ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > >> For additional commands, e-mail: dev-help@pekko.apache.org
> > > > >>
> > > > >>
> > > > >
> > > > > --
> > > > >
> > > > > Matthew de Detrich
> > > > >
> > > > > *Aiven Deutschland GmbH*
> > > > >
> > > > > Immanuelkirchstraße 26, 10405 Berlin
> > > > >
> > > > > Alexanderufer 3-7, 10117 Berlin
> > > > >
> > > > > Amtsgericht Charlottenburg, HRB 209739 B
> > > > >
> > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > > > >
> > > > > *m:* +491603708037
> > > > >
> > > > > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Matthew de Detrich
> > > >
> > > > *Aiven Deutschland GmbH*
> > > >
> > > > Immanuelkirchstraße 26, 10405 Berlin
> > > >
> > > > Alexanderufer 3-7, 10117 Berlin
> > > >
> > > > Amtsgericht Charlottenburg, HRB 209739 B
> > > >
> > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > > >
> > > > *m:* +491603708037
> > > >
> > > > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> > > >
> > >
> >
> >
> > --
> >
> > Matthew de Detrich
> >
> > *Aiven Deutschland GmbH*
> >
> > Immanuelkirchstraße 26, 10405 Berlin
> >
> > Alexanderufer 3-7, 10117 Berlin
> >
> > Amtsgericht Charlottenburg, HRB 209739 B
> >
> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> >
> > *m:* +491603708037
> >
> > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> >
>
--
Matthew de Detrich
*Aiven Deutschland GmbH*
Immanuelkirchstraße 26, 10405 Berlin
Alexanderufer 3-7, 10117 Berlin
Amtsgericht Charlottenburg, HRB 209739 B
Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
*m:* +491603708037
*w:* aiven.io *e:* matthew.dedetrich@aiven.io
Re: having non-LTS releases
Posted by PJ Fanning <fa...@apache.org>.
I would like to add https://github.com/apache/incubator-pekko/pull/765 to
the M1. I think it would be good to get the changes tested.
On Wed 10 Jan 2024, 01:07 Matthew de Detrich,
<ma...@aiven.io.invalid> wrote:
> So I have some good news for one of the big ticket items listed earlier,
> Pekko is now using the latest version of sbt-osgi which contains a lot of
> fixes and
> improvements, see https://github.com/apache/incubator-pekko/pull/920. This
> avoids
> us having to drop sbt-osgi support (doing so is not off the table
> completely but should
> be made as a community decision later). Also
> https://github.com/apache/incubator-pekko/pull/252
> landed which is important since it's a behavioural change.
>
> I would say the only other big item that should be handled before an M1
> vote is
> finishing off the inliner changes,
> https://github.com/apache/incubator-pekko/pull/587
> and the migration of akka to pekko clusters. A milestone release of these
> changes
> will provide ample opportunity for extensive testing to make sure as much
> as possible
> that the full release is without issues. I left out multi-release-jar
> support, my feeling is
> that this is too big of a change for M1 but It might make sense as an M2
> or as part of 1.2.x.
>
> If there is anything that's left out please mention it.
>
> On Sun, Dec 24, 2023 at 7:42 AM kerr <he...@gmail.com> wrote:
>
> > +1 for this, IIRC Matthew suggested this kind of release too.
> > 何品
> >
> >
> > Matthew de Detrich <ma...@aiven.io.invalid> 于2023年12月13日周三
> > 07:06写道：
> >
> > > Apologies for necroing this topic, but there is one other feature I
> would
> > > like to add to the M1
> > > milestone release which is
> > > https://github.com/apache/incubator-pekko/pull/252. The reason I
> > > am pointing out this issue specifically is that it is a breaking
> > behaviour
> > > change (all of the
> > > details are in the PR) so it needs to land for the 1.1.x series,
> ideally
> > > for M1 so we can figure
> > > out if there are any behavioural regressions.
> > >
> > > On Mon, Nov 6, 2023 at 8:40 PM Matthew de Detrich <
> > > matthew.dedetrich@aiven.io> wrote:
> > >
> > > > > Some of those changes will likely also need backporting for
> > > > 1.0.x releases.
> > > >
> > > > Indeed, the rolling migration from Akka to Pekko clusters is
> actually a
> > > > feature for 1.0.x, but because
> > > > of how its designed (i.e. there is a configuration for the
> > > sender/receiver
> > > > address), this feature and
> > > > configuration also needs to exist for Pekko 1.1.0 otherwise the user
> > > > experience will be extremely
> > > > unintuitive.
> > > >
> > > > > I don't think a 1.1.0-M0 is warranted. This git tag has code that
> is
> > > > very similar to Pekko 1.0.1. I don't see the merit in having multiple
> > > > ASF contributors having to review such a release.
> > > >
> > > > It trivializes MiMa management which is worth the annoyance of doing
> a
> > > > release. There really
> > > > isn't any other way without breaking ASF policy, we basically have to
> > > make
> > > > a release that is
> > > > not a "real" release.
> > > >
> > > > One thing to note is this doesn't occur that frequently (i.e. M0
> > > > milestones), i.e. its only on a
> > > > minor version bump and it can be argued that this release can be part
> > of
> > > > the formality of
> > > > when we decide to make a 1.1.x branch, i.e. the community makes a
> > > > decision/vote that
> > > > at a certain point in time we are going to bump the minor version
> which
> > > > requires a vote
> > > > and that some vote is also used for the M0 release.
> > > >
> > > > In fact, now that I think/write about it, we really should have a
> > formal
> > > > vote when we make a
> > > > minor version bump because it is a significant change, it shouldn't
> be
> > > > done at whim (even
> > > > if its from a PMC)
> > > >
> > > > > When I say LTS, I mean what versions will get patches for a long
> > time.
> > > > Java releases are a good example. If an org really needs a Java 22
> > > > feature they can use Java 22 in production - but they are expected to
> > > > upgrade to Java 23, etc. when those versions are released until a new
> > > > Java LTS is released. There are other OSS equivalents. I am not
> > > > talking about Commercial Support contracts - commercial entities are
> > > > very welcome to fill this gap - this does not need to relate directly
> > > > to the FOSS releases from the ASF project team.
> > > >
> > > > I understand the difference between LTS and commercial contract, it's
> > > just
> > > > that
> > > > even the variables for how long the support is, is something that I
> > don't
> > > > think
> > > > we have any ability to estimate concretely now. In summary, in my
> view
> > > > it's too
> > > > soon to even be discussing this.
> > > >
> > > > > If the consensus is to delay Pekko 1.1 until every candidate change
> > is
> > > > made - then fine - but this stops users from using features that are
> > > > ready to try, like the Netty 4 support.
> > > >
> > > > As discussed on the github issue[1], this is a non issue. A milestone
> > > > release
> > > > will cater to anyone who really needs netty4 and as stated, it's just
> > as
> > > > tested
> > > > as any other Pekko release is. If people are really desperate for
> > netty4,
> > > > then
> > > > they can use the milestone (I would also note that I haven't seen any
> > > > indication that anyone is begging for netty4 right now).
> > > >
> > > > > Since Pekko 1.1.0 full release seems like a long way away, it might
> > be
> > > > worth considering mechanisms to release the most useful changes
> > > > earlier - in a way that Pekko 1.0 users can uptake.
> > > >
> > > > This is what milestones are for, i.e. they are precisely the
> mechanism
> > > > to solve this issue. It also solves a host of other issues as
> discussed
> > > > here[2].
> > > >
> > > > [1] https://github.com/apache/incubator-pekko/pull/778
> > > > [2] https://lists.apache.org/thread/o494q89hhg64r5nwv4rnq6fsx9zofmny
> > > >
> > > > On Sun, Nov 5, 2023 at 10:57 PM PJ Fanning <fa...@gmail.com>
> > wrote:
> > > >
> > > >> I have no objections to the general list of changes that we need for
> > > >> 1.1.0. Some of those changes will likely also need backporting for
> > > >> 1.0.x releases.
> > > >>
> > > >> A 1.1.0-M1 release makes sense. I want to delay it by a week or 2
> > > >> while we decide what to do about the config logging (recent Akka
> CVE).
> > > >>
> > > >> I don't think a 1.1.0-M0 is warranted. This git tag has code that is
> > > >> very similar to Pekko 1.0.1. I don't see the merit in having
> multiple
> > > >> ASF contributors having to review such a release.
> > > >>
> > > >> I guess it is a separate conversation but there is a fair degree of
> > > >> resistance to us dropping support for anything. I think we will need
> > > >> to only drop support if it really makes things much easier for us.
> > > >> Multi Release Jars seems like a better option than dropping Java 8
> > > >> support (for instance).
> > > >>
> > > >> When I say LTS, I mean what versions will get patches for a long
> time.
> > > >> Java releases are a good example. If an org really needs a Java 22
> > > >> feature they can use Java 22 in production - but they are expected
> to
> > > >> upgrade to Java 23, etc. when those versions are released until a
> new
> > > >> Java LTS is released. There are other OSS equivalents. I am not
> > > >> talking about Commercial Support contracts - commercial entities are
> > > >> very welcome to fill this gap - this does not need to relate
> directly
> > > >> to the FOSS releases from the ASF project team.
> > > >>
> > > >> If the consensus is to delay Pekko 1.1 until every candidate change
> is
> > > >> made - then fine - but this stops users from using features that are
> > > >> ready to try, like the Netty 4 support.
> > > >>
> > > >> Since Pekko 1.1.0 full release seems like a long way away, it might
> be
> > > >> worth considering mechanisms to release the most useful changes
> > > >> earlier - in a way that Pekko 1.0 users can uptake.
> > > >>
> > > >>
> > > >> On Sun, 5 Nov 2023 at 12:59, Matthew de Detrich
> > > >> <ma...@aiven.io.invalid> wrote:
> > > >> >
> > > >> > So my take on this
> > > >> >
> > > >> > - We should do milestones to solve the general problem you are
> > > alluding
> > > >> to,
> > > >> > i.e. the M1 milestone that you suggest that we vote on (we should
> > also
> > > >> do
> > > >> > the M0 milestone which is at the exact moment when a new bump to
> > minor
> > > >> > version is done, reasoning why is given in this thread[1]). I
> would
> > > >> argue
> > > >> > that doing an M1 now is a good idea and then an M2 once other
> > critical
> > > >> > features land (such as inliner which is mentioned in the below
> > point)
> > > >> > - There are some critical features that need to be merged before a
> > > >> release
> > > >> > of 1.1.0 Pekko Core is ever made (and 1.1.0 Pekko core needs to be
> > > >> released
> > > >> > before any other 1.1.0 releases for the other modules) due to
> > > technical
> > > >> > reasons. On the top of my head the critical features so far are
> the
> > > >> > inliner[2] and rolling update migration of Akka to Pekko
> > clusters[3].
> > > I
> > > >> > think it's achievable to get [2] and [3] done in a few months
> time,
> > > but
> > > >> we
> > > >> > would have to focus on getting it over the line ([2] is already
> > > "done",
> > > >> it
> > > >> > just needs a review and testing in downstream modules, [3] likely
> > > needs
> > > >> > more work and most of all testing so that it works as expected).
> > > >> > - Regarding LTS, I don't think we should entertain the idea now.
> We
> > > >> have no
> > > >> > idea of what and how an LTS can work and we don't even have the
> > > capacity
> > > >> > for it. It might even be a thing that LTS's are "someone else's"
> > > problem
> > > >> > (Pekko is open source after all). I think the most critical thing
> is
> > > >> > sticking to semantic versioning, such an expectation is manageable
> > for
> > > >> us
> > > >> > and I would argue is kind of a requirement for large open source
> > > >> projects
> > > >> > like Pekko
> > > >> > - Fixing the manager name [4] should also be fixed for 1.1.0
> > (actually
> > > >> if
> > > >> > anything this should be fixed for 1.0.x branch as well)
> > > >> > - As kind of a stretch goal, sbt-multi-release-jar support for
> > > 1.1.0[5]
> > > >> > would be awesome as it would unblock a **lot** of things while
> also
> > > >> keeping
> > > >> > part of the community happy
> > > >> > - Releasing pekko 1.1.0 with the latest sbt-osgi (which apparently
> > > >> fixes a
> > > >> > lot of pain points versus the current osgi used in Pekko 1.0.x)
> > would
> > > be
> > > >> > another nice stretch goal, currently there is one issue with
> > duplicate
> > > >> > classes but we now have infrastructure set up[6] so that we can
> > > properly
> > > >> > test such changes.
> > > >> >
> > > >> > Note that a lot of the underlying reasoning behind my points are
> > also
> > > >> > strategic, i.e. keeping features which can be considered critical
> to
> > > >> Pekko
> > > >> > and/or current Akka users which don't require to much effort
> > > (basically
> > > >> > anything that gives a reason for people to use/migrate to Pekko
> > while
> > > >> not
> > > >> > breaking the i.e. our bank so to speak). I know that there has
> been
> > a
> > > >> push
> > > >> > to do things like drop JDK 8, Scala 2.12, osgi etc etc due to
> death
> > > by a
> > > >> > thousand cuts but tbh objectively speaking these issues are not
> > taking
> > > >> up
> > > >> > that much time (at least personally by far the largest amount of
> > time
> > > >> spent
> > > >> > is just overhead of having to do so many releases and validate
> them,
> > > >> really
> > > >> > looking forward to the day when we can automate everything with
> > > >> > sbt-reproducible-builds/jardiff/create jars in ci etc etc). Pekko
> > > 2.0.x
> > > >> > series is when we can look forward to drop a lot of this "annoying
> > > >> > maintenance" stuff and I would actually strongly argue that at the
> > > time
> > > >> > when we start looking at Pekko 2.0.x we actually get a better idea
> > of
> > > >> what
> > > >> > our Pekko users look like, because as has been shown due to the
> > chaos
> > > >> > created from the license change very few us had any somewhat
> > realistic
> > > >> lens
> > > >> > as to how the Pekko community (specifically users) look like, i.e.
> > > while
> > > >> > the OS would **LOVE** to get rid of JDK 1.8 support it just so
> > happens
> > > >> that
> > > >> > a lot of people still need to use JDK 1.8 and even though there
> are
> > > >> reasons
> > > >> > to move away from 1.8 evidently they aren't relevant.
> > > >> >
> > > >> > [1]
> > https://lists.apache.org/thread/o494q89hhg64r5nwv4rnq6fsx9zofmny
> > > >> > [2] https://github.com/apache/incubator-pekko/pull/305
> > > >> > [3] https://github.com/apache/incubator-pekko/pull/765
> > > >> > [4] https://github.com/apache/incubator-pekko/pull/587
> > > >> > [5] https://github.com/sbt/sbt-multi-release-jar/issues/22
> > > >> > [6] https://github.com/apache/incubator-pekko/issues/75
> > > >> >
> > > >> > On Sun, Nov 5, 2023 at 12:12 PM PJ Fanning <fa...@apache.org>
> > > >> wrote:
> > > >> >
> > > >> > > The core pekko repo [1] has quite a few changes in its main
> branch
> > > >> that
> > > >> > > are are targeted at a future 1.1.0 release.
> > > >> > >
> > > >> > > We haven't really agreed on what to do with the code that was
> > > already
> > > >> > > deprecated in the Akka era and there is also the issue of the
> > > >> ApiMayChange
> > > >> > > annotations on some of the APIs.
> > > >> > >
> > > >> > > There are also some new features that developers want to add.
> > > >> > >
> > > >> > > We don't have a great deal of developer effort available to us.
> > > >> > >
> > > >> > > I suspect that we need to need to balance the need to release
> some
> > > of
> > > >> the
> > > >> > > 1.1 changes and then maybe try to make another batch of changes
> in
> > > >> Pekko
> > > >> > > 1.2.
> > > >> > >
> > > >> > > What if we aimed to do a Pekko 1.1.0 release in a few months and
> > > said
> > > >> that
> > > >> > > it was not a Long Term Support release? If we go down this line,
> > we
> > > >> would
> > > >> > > probably want to have a tentative plan as to when a new LTS
> > release
> > > >> would
> > > >> > > happen.
> > > >> > >
> > > >> > > An example of something that would be useful to release would be
> > the
> > > >> > > netty4 support. I know that the Apache Flink team would like to
> > use
> > > >> this.
> > > >> > >
> > > >> > > Alternatively, we could do a Pekko 1.1.0-M1 release. I suspect
> > that
> > > we
> > > >> > > would end up with a fair number of these and the M version
> number
> > > >> would
> > > >> > > discourage uptake (except for testing).
> > > >> > >
> > > >> > > What are people's thoughts on the options?
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > [1] https://github.com/apache/incubator-pekko
> > > >> > >
> > > >> > >
> > > ---------------------------------------------------------------------
> > > >> > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > >> > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > >> > >
> > > >> > >
> > > >> >
> > > >> > --
> > > >> >
> > > >> > Matthew de Detrich
> > > >> >
> > > >> > *Aiven Deutschland GmbH*
> > > >> >
> > > >> > Immanuelkirchstraße 26, 10405 Berlin
> > > >> >
> > > >> > Alexanderufer 3-7, 10117 Berlin
> > > >> >
> > > >> > Amtsgericht Charlottenburg, HRB 209739 B
> > > >> >
> > > >> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > > >> >
> > > >> > *m:* +491603708037
> > > >> >
> > > >> > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > >> For additional commands, e-mail: dev-help@pekko.apache.org
> > > >>
> > > >>
> > > >
> > > > --
> > > >
> > > > Matthew de Detrich
> > > >
> > > > *Aiven Deutschland GmbH*
> > > >
> > > > Immanuelkirchstraße 26, 10405 Berlin
> > > >
> > > > Alexanderufer 3-7, 10117 Berlin
> > > >
> > > > Amtsgericht Charlottenburg, HRB 209739 B
> > > >
> > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > > >
> > > > *m:* +491603708037
> > > >
> > > > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> > > >
> > >
> > >
> > > --
> > >
> > > Matthew de Detrich
> > >
> > > *Aiven Deutschland GmbH*
> > >
> > > Immanuelkirchstraße 26, 10405 Berlin
> > >
> > > Alexanderufer 3-7, 10117 Berlin
> > >
> > > Amtsgericht Charlottenburg, HRB 209739 B
> > >
> > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > >
> > > *m:* +491603708037
> > >
> > > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> > >
> >
>
>
> --
>
> Matthew de Detrich
>
> *Aiven Deutschland GmbH*
>
> Immanuelkirchstraße 26, 10405 Berlin
>
> Alexanderufer 3-7, 10117 Berlin
>
> Amtsgericht Charlottenburg, HRB 209739 B
>
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
>
> *m:* +491603708037
>
> *w:* aiven.io *e:* matthew.dedetrich@aiven.io
>
Re: having non-LTS releases
Posted by kerr <he...@gmail.com>.
GOGOGOGO
何品
Matthew de Detrich <ma...@aiven.io.invalid> 于2024年1月23日周二
07:19写道：
> I would also like to add
> https://github.com/apache/incubator-pekko/pull/981
> onto the list
> for M1. When originally making the feature request I incorrectly assumed
> that
> Supervision.Resume didn't make sense however that turns out to not be the
> case.
>
> I think the basis of the feature is already implemented in the PR, just
> need to add tests
> and update documentation.
>
> On Mon, Jan 15, 2024 at 4:13 PM kerr <he...@gmail.com> wrote:
>
> > Should we support limit the max forkjoinpool in 1.1.x? there is a pending
> > pr, I think it would be nice to included in.
> >
> > Virtual thread can limit it with `
> > -Djdk.virtualThreadScheduler.maxPoolSize=256"`
> >
> > 何品
> >
> >
> > Matthew de Detrich <ma...@aiven.io.invalid> 于2024年1月15日周一
> > 09:33写道：
> >
> > > Regarding mult-release JAR support, I did some initial work[1] and I
> > think
> > > that this
> > > will have to wait, possible for SBT 2.x since there are fundamental
> > > limitations in sbt
> > > to properly support this.
> > >
> > > Note that its still technically possible, but in doing so we have to
> > > statically define
> > > a set of keys (i.e. SBT SettingKey) for **every** JDK version that we
> > want
> > > to build
> > > and since we are already at JDK 21 this can get unwieldy pretty
> quickly.
> > >
> > > [1]
> > >
> > >
> >
> https://github.com/sbt/sbt-multi-release-jar/issues/24#issuecomment-1891156070
> > >
> > > On Wed, Jan 10, 2024 at 11:06 AM Matthew de Detrich <
> > > matthew.dedetrich@aiven.io> wrote:
> > >
> > > > So I have some good news for one of the big ticket items listed
> > earlier,
> > > > Pekko is now using the latest version of sbt-osgi which contains a
> lot
> > of
> > > > fixes and
> > > > improvements, see https://github.com/apache/incubator-pekko/pull/920
> .
> > > > This avoids
> > > > us having to drop sbt-osgi support (doing so is not off the table
> > > > completely but should
> > > > be made as a community decision later). Also
> > > > https://github.com/apache/incubator-pekko/pull/252
> > > > landed which is important since it's a behavioural change.
> > > >
> > > > I would say the only other big item that should be handled before an
> M1
> > > > vote is
> > > > finishing off the inliner changes,
> > > > https://github.com/apache/incubator-pekko/pull/587
> > > > and the migration of akka to pekko clusters. A milestone release of
> > these
> > > > changes
> > > > will provide ample opportunity for extensive testing to make sure as
> > much
> > > > as possible
> > > > that the full release is without issues. I left out multi-release-jar
> > > > support, my feeling is
> > > > that this is too big of a change for M1 but It might make sense as
> an
> > M2
> > > > or as part of 1.2.x.
> > > >
> > > > If there is anything that's left out please mention it.
> > > >
> > > > On Sun, Dec 24, 2023 at 7:42 AM kerr <he...@gmail.com> wrote:
> > > >
> > > >> +1 for this, IIRC Matthew suggested this kind of release too.
> > > >> 何品
> > > >>
> > > >>
> > > >> Matthew de Detrich <ma...@aiven.io.invalid>
> > 于2023年12月13日周三
> > > >> 07:06写道：
> > > >>
> > > >> > Apologies for necroing this topic, but there is one other feature
> I
> > > >> would
> > > >> > like to add to the M1
> > > >> > milestone release which is
> > > >> > https://github.com/apache/incubator-pekko/pull/252. The reason I
> > > >> > am pointing out this issue specifically is that it is a breaking
> > > >> behaviour
> > > >> > change (all of the
> > > >> > details are in the PR) so it needs to land for the 1.1.x series,
> > > ideally
> > > >> > for M1 so we can figure
> > > >> > out if there are any behavioural regressions.
> > > >> >
> > > >> > On Mon, Nov 6, 2023 at 8:40 PM Matthew de Detrich <
> > > >> > matthew.dedetrich@aiven.io> wrote:
> > > >> >
> > > >> > > > Some of those changes will likely also need backporting for
> > > >> > > 1.0.x releases.
> > > >> > >
> > > >> > > Indeed, the rolling migration from Akka to Pekko clusters is
> > > actually
> > > >> a
> > > >> > > feature for 1.0.x, but because
> > > >> > > of how its designed (i.e. there is a configuration for the
> > > >> > sender/receiver
> > > >> > > address), this feature and
> > > >> > > configuration also needs to exist for Pekko 1.1.0 otherwise the
> > user
> > > >> > > experience will be extremely
> > > >> > > unintuitive.
> > > >> > >
> > > >> > > > I don't think a 1.1.0-M0 is warranted. This git tag has code
> > that
> > > is
> > > >> > > very similar to Pekko 1.0.1. I don't see the merit in having
> > > multiple
> > > >> > > ASF contributors having to review such a release.
> > > >> > >
> > > >> > > It trivializes MiMa management which is worth the annoyance of
> > > doing a
> > > >> > > release. There really
> > > >> > > isn't any other way without breaking ASF policy, we basically
> have
> > > to
> > > >> > make
> > > >> > > a release that is
> > > >> > > not a "real" release.
> > > >> > >
> > > >> > > One thing to note is this doesn't occur that frequently (i.e. M0
> > > >> > > milestones), i.e. its only on a
> > > >> > > minor version bump and it can be argued that this release can be
> > > part
> > > >> of
> > > >> > > the formality of
> > > >> > > when we decide to make a 1.1.x branch, i.e. the community makes
> a
> > > >> > > decision/vote that
> > > >> > > at a certain point in time we are going to bump the minor
> version
> > > >> which
> > > >> > > requires a vote
> > > >> > > and that some vote is also used for the M0 release.
> > > >> > >
> > > >> > > In fact, now that I think/write about it, we really should have
> a
> > > >> formal
> > > >> > > vote when we make a
> > > >> > > minor version bump because it is a significant change, it
> > shouldn't
> > > be
> > > >> > > done at whim (even
> > > >> > > if its from a PMC)
> > > >> > >
> > > >> > > > When I say LTS, I mean what versions will get patches for a
> long
> > > >> time.
> > > >> > > Java releases are a good example. If an org really needs a Java
> 22
> > > >> > > feature they can use Java 22 in production - but they are
> expected
> > > to
> > > >> > > upgrade to Java 23, etc. when those versions are released until
> a
> > > new
> > > >> > > Java LTS is released. There are other OSS equivalents. I am not
> > > >> > > talking about Commercial Support contracts - commercial entities
> > are
> > > >> > > very welcome to fill this gap - this does not need to relate
> > > directly
> > > >> > > to the FOSS releases from the ASF project team.
> > > >> > >
> > > >> > > I understand the difference between LTS and commercial contract,
> > > it's
> > > >> > just
> > > >> > > that
> > > >> > > even the variables for how long the support is, is something
> that
> > I
> > > >> don't
> > > >> > > think
> > > >> > > we have any ability to estimate concretely now. In summary, in
> my
> > > view
> > > >> > > it's too
> > > >> > > soon to even be discussing this.
> > > >> > >
> > > >> > > > If the consensus is to delay Pekko 1.1 until every candidate
> > > change
> > > >> is
> > > >> > > made - then fine - but this stops users from using features that
> > are
> > > >> > > ready to try, like the Netty 4 support.
> > > >> > >
> > > >> > > As discussed on the github issue[1], this is a non issue. A
> > > milestone
> > > >> > > release
> > > >> > > will cater to anyone who really needs netty4 and as stated, it's
> > > just
> > > >> as
> > > >> > > tested
> > > >> > > as any other Pekko release is. If people are really desperate
> for
> > > >> netty4,
> > > >> > > then
> > > >> > > they can use the milestone (I would also note that I haven't
> seen
> > > any
> > > >> > > indication that anyone is begging for netty4 right now).
> > > >> > >
> > > >> > > > Since Pekko 1.1.0 full release seems like a long way away, it
> > > might
> > > >> be
> > > >> > > worth considering mechanisms to release the most useful changes
> > > >> > > earlier - in a way that Pekko 1.0 users can uptake.
> > > >> > >
> > > >> > > This is what milestones are for, i.e. they are precisely the
> > > mechanism
> > > >> > > to solve this issue. It also solves a host of other issues as
> > > >> discussed
> > > >> > > here[2].
> > > >> > >
> > > >> > > [1] https://github.com/apache/incubator-pekko/pull/778
> > > >> > > [2]
> > > https://lists.apache.org/thread/o494q89hhg64r5nwv4rnq6fsx9zofmny
> > > >> > >
> > > >> > > On Sun, Nov 5, 2023 at 10:57 PM PJ Fanning <fanningpj@gmail.com
> >
> > > >> wrote:
> > > >> > >
> > > >> > >> I have no objections to the general list of changes that we
> need
> > > for
> > > >> > >> 1.1.0. Some of those changes will likely also need backporting
> > for
> > > >> > >> 1.0.x releases.
> > > >> > >>
> > > >> > >> A 1.1.0-M1 release makes sense. I want to delay it by a week
> or 2
> > > >> > >> while we decide what to do about the config logging (recent
> Akka
> > > >> CVE).
> > > >> > >>
> > > >> > >> I don't think a 1.1.0-M0 is warranted. This git tag has code
> that
> > > is
> > > >> > >> very similar to Pekko 1.0.1. I don't see the merit in having
> > > multiple
> > > >> > >> ASF contributors having to review such a release.
> > > >> > >>
> > > >> > >> I guess it is a separate conversation but there is a fair
> degree
> > of
> > > >> > >> resistance to us dropping support for anything. I think we will
> > > need
> > > >> > >> to only drop support if it really makes things much easier for
> > us.
> > > >> > >> Multi Release Jars seems like a better option than dropping
> Java
> > 8
> > > >> > >> support (for instance).
> > > >> > >>
> > > >> > >> When I say LTS, I mean what versions will get patches for a
> long
> > > >> time.
> > > >> > >> Java releases are a good example. If an org really needs a Java
> > 22
> > > >> > >> feature they can use Java 22 in production - but they are
> > expected
> > > to
> > > >> > >> upgrade to Java 23, etc. when those versions are released
> until a
> > > new
> > > >> > >> Java LTS is released. There are other OSS equivalents. I am not
> > > >> > >> talking about Commercial Support contracts - commercial
> entities
> > > are
> > > >> > >> very welcome to fill this gap - this does not need to relate
> > > directly
> > > >> > >> to the FOSS releases from the ASF project team.
> > > >> > >>
> > > >> > >> If the consensus is to delay Pekko 1.1 until every candidate
> > change
> > > >> is
> > > >> > >> made - then fine - but this stops users from using features
> that
> > > are
> > > >> > >> ready to try, like the Netty 4 support.
> > > >> > >>
> > > >> > >> Since Pekko 1.1.0 full release seems like a long way away, it
> > might
> > > >> be
> > > >> > >> worth considering mechanisms to release the most useful changes
> > > >> > >> earlier - in a way that Pekko 1.0 users can uptake.
> > > >> > >>
> > > >> > >>
> > > >> > >> On Sun, 5 Nov 2023 at 12:59, Matthew de Detrich
> > > >> > >> <ma...@aiven.io.invalid> wrote:
> > > >> > >> >
> > > >> > >> > So my take on this
> > > >> > >> >
> > > >> > >> > - We should do milestones to solve the general problem you
> are
> > > >> > alluding
> > > >> > >> to,
> > > >> > >> > i.e. the M1 milestone that you suggest that we vote on (we
> > should
> > > >> also
> > > >> > >> do
> > > >> > >> > the M0 milestone which is at the exact moment when a new bump
> > to
> > > >> minor
> > > >> > >> > version is done, reasoning why is given in this thread[1]). I
> > > would
> > > >> > >> argue
> > > >> > >> > that doing an M1 now is a good idea and then an M2 once other
> > > >> critical
> > > >> > >> > features land (such as inliner which is mentioned in the
> below
> > > >> point)
> > > >> > >> > - There are some critical features that need to be merged
> > before
> > > a
> > > >> > >> release
> > > >> > >> > of 1.1.0 Pekko Core is ever made (and 1.1.0 Pekko core needs
> to
> > > be
> > > >> > >> released
> > > >> > >> > before any other 1.1.0 releases for the other modules) due to
> > > >> > technical
> > > >> > >> > reasons. On the top of my head the critical features so far
> are
> > > the
> > > >> > >> > inliner[2] and rolling update migration of Akka to Pekko
> > > >> clusters[3].
> > > >> > I
> > > >> > >> > think it's achievable to get [2] and [3] done in a few months
> > > time,
> > > >> > but
> > > >> > >> we
> > > >> > >> > would have to focus on getting it over the line ([2] is
> already
> > > >> > "done",
> > > >> > >> it
> > > >> > >> > just needs a review and testing in downstream modules, [3]
> > likely
> > > >> > needs
> > > >> > >> > more work and most of all testing so that it works as
> > expected).
> > > >> > >> > - Regarding LTS, I don't think we should entertain the idea
> > now.
> > > We
> > > >> > >> have no
> > > >> > >> > idea of what and how an LTS can work and we don't even have
> the
> > > >> > capacity
> > > >> > >> > for it. It might even be a thing that LTS's are "someone
> > else's"
> > > >> > problem
> > > >> > >> > (Pekko is open source after all). I think the most critical
> > thing
> > > >> is
> > > >> > >> > sticking to semantic versioning, such an expectation is
> > > manageable
> > > >> for
> > > >> > >> us
> > > >> > >> > and I would argue is kind of a requirement for large open
> > source
> > > >> > >> projects
> > > >> > >> > like Pekko
> > > >> > >> > - Fixing the manager name [4] should also be fixed for 1.1.0
> > > >> (actually
> > > >> > >> if
> > > >> > >> > anything this should be fixed for 1.0.x branch as well)
> > > >> > >> > - As kind of a stretch goal, sbt-multi-release-jar support
> for
> > > >> > 1.1.0[5]
> > > >> > >> > would be awesome as it would unblock a **lot** of things
> while
> > > also
> > > >> > >> keeping
> > > >> > >> > part of the community happy
> > > >> > >> > - Releasing pekko 1.1.0 with the latest sbt-osgi (which
> > > apparently
> > > >> > >> fixes a
> > > >> > >> > lot of pain points versus the current osgi used in Pekko
> 1.0.x)
> > > >> would
> > > >> > be
> > > >> > >> > another nice stretch goal, currently there is one issue with
> > > >> duplicate
> > > >> > >> > classes but we now have infrastructure set up[6] so that we
> can
> > > >> > properly
> > > >> > >> > test such changes.
> > > >> > >> >
> > > >> > >> > Note that a lot of the underlying reasoning behind my points
> > are
> > > >> also
> > > >> > >> > strategic, i.e. keeping features which can be considered
> > critical
> > > >> to
> > > >> > >> Pekko
> > > >> > >> > and/or current Akka users which don't require to much effort
> > > >> > (basically
> > > >> > >> > anything that gives a reason for people to use/migrate to
> Pekko
> > > >> while
> > > >> > >> not
> > > >> > >> > breaking the i.e. our bank so to speak). I know that there
> has
> > > >> been a
> > > >> > >> push
> > > >> > >> > to do things like drop JDK 8, Scala 2.12, osgi etc etc due to
> > > death
> > > >> > by a
> > > >> > >> > thousand cuts but tbh objectively speaking these issues are
> not
> > > >> taking
> > > >> > >> up
> > > >> > >> > that much time (at least personally by far the largest amount
> > of
> > > >> time
> > > >> > >> spent
> > > >> > >> > is just overhead of having to do so many releases and
> validate
> > > >> them,
> > > >> > >> really
> > > >> > >> > looking forward to the day when we can automate everything
> with
> > > >> > >> > sbt-reproducible-builds/jardiff/create jars in ci etc etc).
> > Pekko
> > > >> > 2.0.x
> > > >> > >> > series is when we can look forward to drop a lot of this
> > > "annoying
> > > >> > >> > maintenance" stuff and I would actually strongly argue that
> at
> > > the
> > > >> > time
> > > >> > >> > when we start looking at Pekko 2.0.x we actually get a better
> > > idea
> > > >> of
> > > >> > >> what
> > > >> > >> > our Pekko users look like, because as has been shown due to
> the
> > > >> chaos
> > > >> > >> > created from the license change very few us had any somewhat
> > > >> realistic
> > > >> > >> lens
> > > >> > >> > as to how the Pekko community (specifically users) look like,
> > > i.e.
> > > >> > while
> > > >> > >> > the OS would **LOVE** to get rid of JDK 1.8 support it just
> so
> > > >> happens
> > > >> > >> that
> > > >> > >> > a lot of people still need to use JDK 1.8 and even though
> there
> > > are
> > > >> > >> reasons
> > > >> > >> > to move away from 1.8 evidently they aren't relevant.
> > > >> > >> >
> > > >> > >> > [1]
> > > >> https://lists.apache.org/thread/o494q89hhg64r5nwv4rnq6fsx9zofmny
> > > >> > >> > [2] https://github.com/apache/incubator-pekko/pull/305
> > > >> > >> > [3] https://github.com/apache/incubator-pekko/pull/765
> > > >> > >> > [4] https://github.com/apache/incubator-pekko/pull/587
> > > >> > >> > [5] https://github.com/sbt/sbt-multi-release-jar/issues/22
> > > >> > >> > [6] https://github.com/apache/incubator-pekko/issues/75
> > > >> > >> >
> > > >> > >> > On Sun, Nov 5, 2023 at 12:12 PM PJ Fanning <
> > fanningpj@apache.org
> > > >
> > > >> > >> wrote:
> > > >> > >> >
> > > >> > >> > > The core pekko repo [1] has quite a few changes in its main
> > > >> branch
> > > >> > >> that
> > > >> > >> > > are are targeted at a future 1.1.0 release.
> > > >> > >> > >
> > > >> > >> > > We haven't really agreed on what to do with the code that
> was
> > > >> > already
> > > >> > >> > > deprecated in the Akka era and there is also the issue of
> the
> > > >> > >> ApiMayChange
> > > >> > >> > > annotations on some of the APIs.
> > > >> > >> > >
> > > >> > >> > > There are also some new features that developers want to
> add.
> > > >> > >> > >
> > > >> > >> > > We don't have a great deal of developer effort available to
> > us.
> > > >> > >> > >
> > > >> > >> > > I suspect that we need to need to balance the need to
> release
> > > >> some
> > > >> > of
> > > >> > >> the
> > > >> > >> > > 1.1 changes and then maybe try to make another batch of
> > changes
> > > >> in
> > > >> > >> Pekko
> > > >> > >> > > 1.2.
> > > >> > >> > >
> > > >> > >> > > What if we aimed to do a Pekko 1.1.0 release in a few
> months
> > > and
> > > >> > said
> > > >> > >> that
> > > >> > >> > > it was not a Long Term Support release? If we go down this
> > > line,
> > > >> we
> > > >> > >> would
> > > >> > >> > > probably want to have a tentative plan as to when a new LTS
> > > >> release
> > > >> > >> would
> > > >> > >> > > happen.
> > > >> > >> > >
> > > >> > >> > > An example of something that would be useful to release
> would
> > > be
> > > >> the
> > > >> > >> > > netty4 support. I know that the Apache Flink team would
> like
> > to
> > > >> use
> > > >> > >> this.
> > > >> > >> > >
> > > >> > >> > > Alternatively, we could do a Pekko 1.1.0-M1 release. I
> > suspect
> > > >> that
> > > >> > we
> > > >> > >> > > would end up with a fair number of these and the M version
> > > number
> > > >> > >> would
> > > >> > >> > > discourage uptake (except for testing).
> > > >> > >> > >
> > > >> > >> > > What are people's thoughts on the options?
> > > >> > >> > >
> > > >> > >> > >
> > > >> > >> > >
> > > >> > >> > > [1] https://github.com/apache/incubator-pekko
> > > >> > >> > >
> > > >> > >> > >
> > > >> >
> > ---------------------------------------------------------------------
> > > >> > >> > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > >> > >> > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > >> > >> > >
> > > >> > >> > >
> > > >> > >> >
> > > >> > >> > --
> > > >> > >> >
> > > >> > >> > Matthew de Detrich
> > > >> > >> >
> > > >> > >> > *Aiven Deutschland GmbH*
> > > >> > >> >
> > > >> > >> > Immanuelkirchstraße 26, 10405 Berlin
> > > >> > >> >
> > > >> > >> > Alexanderufer 3-7, 10117 Berlin
> > > >> > >> >
> > > >> > >> > Amtsgericht Charlottenburg, HRB 209739 B
> > > >> > >> >
> > > >> > >> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > > >> > >> >
> > > >> > >> > *m:* +491603708037
> > > >> > >> >
> > > >> > >> > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> > > >> > >>
> > > >> > >>
> > > ---------------------------------------------------------------------
> > > >> > >> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > >> > >> For additional commands, e-mail: dev-help@pekko.apache.org
> > > >> > >>
> > > >> > >>
> > > >> > >
> > > >> > > --
> > > >> > >
> > > >> > > Matthew de Detrich
> > > >> > >
> > > >> > > *Aiven Deutschland GmbH*
> > > >> > >
> > > >> > > Immanuelkirchstraße 26, 10405 Berlin
> > > >> > >
> > > >> > > Alexanderufer 3-7, 10117 Berlin
> > > >> > >
> > > >> > > Amtsgericht Charlottenburg, HRB 209739 B
> > > >> > >
> > > >> > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > > >> > >
> > > >> > > *m:* +491603708037
> > > >> > >
> > > >> > > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> > > >> > >
> > > >> >
> > > >> >
> > > >> > --
> > > >> >
> > > >> > Matthew de Detrich
> > > >> >
> > > >> > *Aiven Deutschland GmbH*
> > > >> >
> > > >> > Immanuelkirchstraße 26, 10405 Berlin
> > > >> >
> > > >> > Alexanderufer 3-7, 10117 Berlin
> > > >> >
> > > >> > Amtsgericht Charlottenburg, HRB 209739 B
> > > >> >
> > > >> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > > >> >
> > > >> > *m:* +491603708037
> > > >> >
> > > >> > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> > > >> >
> > > >>
> > > >
> > > >
> > > > --
> > > >
> > > > Matthew de Detrich
> > > >
> > > > *Aiven Deutschland GmbH*
> > > >
> > > > Immanuelkirchstraße 26, 10405 Berlin
> > > >
> > > > Alexanderufer 3-7, 10117 Berlin
> > > >
> > > > Amtsgericht Charlottenburg, HRB 209739 B
> > > >
> > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > > >
> > > > *m:* +491603708037
> > > >
> > > > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> > > >
> > >
> > >
> > > --
> > >
> > > Matthew de Detrich
> > >
> > > *Aiven Deutschland GmbH*
> > >
> > > Immanuelkirchstraße 26, 10405 Berlin
> > >
> > > Alexanderufer 3-7, 10117 Berlin
> > >
> > > Amtsgericht Charlottenburg, HRB 209739 B
> > >
> > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > >
> > > *m:* +491603708037
> > >
> > > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> > >
> >
>
>
> --
>
> Matthew de Detrich
>
> *Aiven Deutschland GmbH*
>
> Immanuelkirchstraße 26, 10405 Berlin
>
> Alexanderufer 3-7, 10117 Berlin
>
> Amtsgericht Charlottenburg, HRB 209739 B
>
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
>
> *m:* +491603708037
>
> *w:* aiven.io *e:* matthew.dedetrich@aiven.io
>
Re: having non-LTS releases
Posted by Matthew de Detrich <ma...@aiven.io.INVALID>.
I would also like to add https://github.com/apache/incubator-pekko/pull/981
onto the list
for M1. When originally making the feature request I incorrectly assumed
that
Supervision.Resume didn't make sense however that turns out to not be the
case.
I think the basis of the feature is already implemented in the PR, just
need to add tests
and update documentation.
On Mon, Jan 15, 2024 at 4:13 PM kerr <he...@gmail.com> wrote:
> Should we support limit the max forkjoinpool in 1.1.x? there is a pending
> pr, I think it would be nice to included in.
>
> Virtual thread can limit it with `
> -Djdk.virtualThreadScheduler.maxPoolSize=256"`
>
> 何品
>
>
> Matthew de Detrich <ma...@aiven.io.invalid> 于2024年1月15日周一
> 09:33写道：
>
> > Regarding mult-release JAR support, I did some initial work[1] and I
> think
> > that this
> > will have to wait, possible for SBT 2.x since there are fundamental
> > limitations in sbt
> > to properly support this.
> >
> > Note that its still technically possible, but in doing so we have to
> > statically define
> > a set of keys (i.e. SBT SettingKey) for **every** JDK version that we
> want
> > to build
> > and since we are already at JDK 21 this can get unwieldy pretty quickly.
> >
> > [1]
> >
> >
> https://github.com/sbt/sbt-multi-release-jar/issues/24#issuecomment-1891156070
> >
> > On Wed, Jan 10, 2024 at 11:06 AM Matthew de Detrich <
> > matthew.dedetrich@aiven.io> wrote:
> >
> > > So I have some good news for one of the big ticket items listed
> earlier,
> > > Pekko is now using the latest version of sbt-osgi which contains a lot
> of
> > > fixes and
> > > improvements, see https://github.com/apache/incubator-pekko/pull/920.
> > > This avoids
> > > us having to drop sbt-osgi support (doing so is not off the table
> > > completely but should
> > > be made as a community decision later). Also
> > > https://github.com/apache/incubator-pekko/pull/252
> > > landed which is important since it's a behavioural change.
> > >
> > > I would say the only other big item that should be handled before an M1
> > > vote is
> > > finishing off the inliner changes,
> > > https://github.com/apache/incubator-pekko/pull/587
> > > and the migration of akka to pekko clusters. A milestone release of
> these
> > > changes
> > > will provide ample opportunity for extensive testing to make sure as
> much
> > > as possible
> > > that the full release is without issues. I left out multi-release-jar
> > > support, my feeling is
> > > that this is too big of a change for M1 but It might make sense as an
> M2
> > > or as part of 1.2.x.
> > >
> > > If there is anything that's left out please mention it.
> > >
> > > On Sun, Dec 24, 2023 at 7:42 AM kerr <he...@gmail.com> wrote:
> > >
> > >> +1 for this, IIRC Matthew suggested this kind of release too.
> > >> 何品
> > >>
> > >>
> > >> Matthew de Detrich <ma...@aiven.io.invalid>
> 于2023年12月13日周三
> > >> 07:06写道：
> > >>
> > >> > Apologies for necroing this topic, but there is one other feature I
> > >> would
> > >> > like to add to the M1
> > >> > milestone release which is
> > >> > https://github.com/apache/incubator-pekko/pull/252. The reason I
> > >> > am pointing out this issue specifically is that it is a breaking
> > >> behaviour
> > >> > change (all of the
> > >> > details are in the PR) so it needs to land for the 1.1.x series,
> > ideally
> > >> > for M1 so we can figure
> > >> > out if there are any behavioural regressions.
> > >> >
> > >> > On Mon, Nov 6, 2023 at 8:40 PM Matthew de Detrich <
> > >> > matthew.dedetrich@aiven.io> wrote:
> > >> >
> > >> > > > Some of those changes will likely also need backporting for
> > >> > > 1.0.x releases.
> > >> > >
> > >> > > Indeed, the rolling migration from Akka to Pekko clusters is
> > actually
> > >> a
> > >> > > feature for 1.0.x, but because
> > >> > > of how its designed (i.e. there is a configuration for the
> > >> > sender/receiver
> > >> > > address), this feature and
> > >> > > configuration also needs to exist for Pekko 1.1.0 otherwise the
> user
> > >> > > experience will be extremely
> > >> > > unintuitive.
> > >> > >
> > >> > > > I don't think a 1.1.0-M0 is warranted. This git tag has code
> that
> > is
> > >> > > very similar to Pekko 1.0.1. I don't see the merit in having
> > multiple
> > >> > > ASF contributors having to review such a release.
> > >> > >
> > >> > > It trivializes MiMa management which is worth the annoyance of
> > doing a
> > >> > > release. There really
> > >> > > isn't any other way without breaking ASF policy, we basically have
> > to
> > >> > make
> > >> > > a release that is
> > >> > > not a "real" release.
> > >> > >
> > >> > > One thing to note is this doesn't occur that frequently (i.e. M0
> > >> > > milestones), i.e. its only on a
> > >> > > minor version bump and it can be argued that this release can be
> > part
> > >> of
> > >> > > the formality of
> > >> > > when we decide to make a 1.1.x branch, i.e. the community makes a
> > >> > > decision/vote that
> > >> > > at a certain point in time we are going to bump the minor version
> > >> which
> > >> > > requires a vote
> > >> > > and that some vote is also used for the M0 release.
> > >> > >
> > >> > > In fact, now that I think/write about it, we really should have a
> > >> formal
> > >> > > vote when we make a
> > >> > > minor version bump because it is a significant change, it
> shouldn't
> > be
> > >> > > done at whim (even
> > >> > > if its from a PMC)
> > >> > >
> > >> > > > When I say LTS, I mean what versions will get patches for a long
> > >> time.
> > >> > > Java releases are a good example. If an org really needs a Java 22
> > >> > > feature they can use Java 22 in production - but they are expected
> > to
> > >> > > upgrade to Java 23, etc. when those versions are released until a
> > new
> > >> > > Java LTS is released. There are other OSS equivalents. I am not
> > >> > > talking about Commercial Support contracts - commercial entities
> are
> > >> > > very welcome to fill this gap - this does not need to relate
> > directly
> > >> > > to the FOSS releases from the ASF project team.
> > >> > >
> > >> > > I understand the difference between LTS and commercial contract,
> > it's
> > >> > just
> > >> > > that
> > >> > > even the variables for how long the support is, is something that
> I
> > >> don't
> > >> > > think
> > >> > > we have any ability to estimate concretely now. In summary, in my
> > view
> > >> > > it's too
> > >> > > soon to even be discussing this.
> > >> > >
> > >> > > > If the consensus is to delay Pekko 1.1 until every candidate
> > change
> > >> is
> > >> > > made - then fine - but this stops users from using features that
> are
> > >> > > ready to try, like the Netty 4 support.
> > >> > >
> > >> > > As discussed on the github issue[1], this is a non issue. A
> > milestone
> > >> > > release
> > >> > > will cater to anyone who really needs netty4 and as stated, it's
> > just
> > >> as
> > >> > > tested
> > >> > > as any other Pekko release is. If people are really desperate for
> > >> netty4,
> > >> > > then
> > >> > > they can use the milestone (I would also note that I haven't seen
> > any
> > >> > > indication that anyone is begging for netty4 right now).
> > >> > >
> > >> > > > Since Pekko 1.1.0 full release seems like a long way away, it
> > might
> > >> be
> > >> > > worth considering mechanisms to release the most useful changes
> > >> > > earlier - in a way that Pekko 1.0 users can uptake.
> > >> > >
> > >> > > This is what milestones are for, i.e. they are precisely the
> > mechanism
> > >> > > to solve this issue. It also solves a host of other issues as
> > >> discussed
> > >> > > here[2].
> > >> > >
> > >> > > [1] https://github.com/apache/incubator-pekko/pull/778
> > >> > > [2]
> > https://lists.apache.org/thread/o494q89hhg64r5nwv4rnq6fsx9zofmny
> > >> > >
> > >> > > On Sun, Nov 5, 2023 at 10:57 PM PJ Fanning <fa...@gmail.com>
> > >> wrote:
> > >> > >
> > >> > >> I have no objections to the general list of changes that we need
> > for
> > >> > >> 1.1.0. Some of those changes will likely also need backporting
> for
> > >> > >> 1.0.x releases.
> > >> > >>
> > >> > >> A 1.1.0-M1 release makes sense. I want to delay it by a week or 2
> > >> > >> while we decide what to do about the config logging (recent Akka
> > >> CVE).
> > >> > >>
> > >> > >> I don't think a 1.1.0-M0 is warranted. This git tag has code that
> > is
> > >> > >> very similar to Pekko 1.0.1. I don't see the merit in having
> > multiple
> > >> > >> ASF contributors having to review such a release.
> > >> > >>
> > >> > >> I guess it is a separate conversation but there is a fair degree
> of
> > >> > >> resistance to us dropping support for anything. I think we will
> > need
> > >> > >> to only drop support if it really makes things much easier for
> us.
> > >> > >> Multi Release Jars seems like a better option than dropping Java
> 8
> > >> > >> support (for instance).
> > >> > >>
> > >> > >> When I say LTS, I mean what versions will get patches for a long
> > >> time.
> > >> > >> Java releases are a good example. If an org really needs a Java
> 22
> > >> > >> feature they can use Java 22 in production - but they are
> expected
> > to
> > >> > >> upgrade to Java 23, etc. when those versions are released until a
> > new
> > >> > >> Java LTS is released. There are other OSS equivalents. I am not
> > >> > >> talking about Commercial Support contracts - commercial entities
> > are
> > >> > >> very welcome to fill this gap - this does not need to relate
> > directly
> > >> > >> to the FOSS releases from the ASF project team.
> > >> > >>
> > >> > >> If the consensus is to delay Pekko 1.1 until every candidate
> change
> > >> is
> > >> > >> made - then fine - but this stops users from using features that
> > are
> > >> > >> ready to try, like the Netty 4 support.
> > >> > >>
> > >> > >> Since Pekko 1.1.0 full release seems like a long way away, it
> might
> > >> be
> > >> > >> worth considering mechanisms to release the most useful changes
> > >> > >> earlier - in a way that Pekko 1.0 users can uptake.
> > >> > >>
> > >> > >>
> > >> > >> On Sun, 5 Nov 2023 at 12:59, Matthew de Detrich
> > >> > >> <ma...@aiven.io.invalid> wrote:
> > >> > >> >
> > >> > >> > So my take on this
> > >> > >> >
> > >> > >> > - We should do milestones to solve the general problem you are
> > >> > alluding
> > >> > >> to,
> > >> > >> > i.e. the M1 milestone that you suggest that we vote on (we
> should
> > >> also
> > >> > >> do
> > >> > >> > the M0 milestone which is at the exact moment when a new bump
> to
> > >> minor
> > >> > >> > version is done, reasoning why is given in this thread[1]). I
> > would
> > >> > >> argue
> > >> > >> > that doing an M1 now is a good idea and then an M2 once other
> > >> critical
> > >> > >> > features land (such as inliner which is mentioned in the below
> > >> point)
> > >> > >> > - There are some critical features that need to be merged
> before
> > a
> > >> > >> release
> > >> > >> > of 1.1.0 Pekko Core is ever made (and 1.1.0 Pekko core needs to
> > be
> > >> > >> released
> > >> > >> > before any other 1.1.0 releases for the other modules) due to
> > >> > technical
> > >> > >> > reasons. On the top of my head the critical features so far are
> > the
> > >> > >> > inliner[2] and rolling update migration of Akka to Pekko
> > >> clusters[3].
> > >> > I
> > >> > >> > think it's achievable to get [2] and [3] done in a few months
> > time,
> > >> > but
> > >> > >> we
> > >> > >> > would have to focus on getting it over the line ([2] is already
> > >> > "done",
> > >> > >> it
> > >> > >> > just needs a review and testing in downstream modules, [3]
> likely
> > >> > needs
> > >> > >> > more work and most of all testing so that it works as
> expected).
> > >> > >> > - Regarding LTS, I don't think we should entertain the idea
> now.
> > We
> > >> > >> have no
> > >> > >> > idea of what and how an LTS can work and we don't even have the
> > >> > capacity
> > >> > >> > for it. It might even be a thing that LTS's are "someone
> else's"
> > >> > problem
> > >> > >> > (Pekko is open source after all). I think the most critical
> thing
> > >> is
> > >> > >> > sticking to semantic versioning, such an expectation is
> > manageable
> > >> for
> > >> > >> us
> > >> > >> > and I would argue is kind of a requirement for large open
> source
> > >> > >> projects
> > >> > >> > like Pekko
> > >> > >> > - Fixing the manager name [4] should also be fixed for 1.1.0
> > >> (actually
> > >> > >> if
> > >> > >> > anything this should be fixed for 1.0.x branch as well)
> > >> > >> > - As kind of a stretch goal, sbt-multi-release-jar support for
> > >> > 1.1.0[5]
> > >> > >> > would be awesome as it would unblock a **lot** of things while
> > also
> > >> > >> keeping
> > >> > >> > part of the community happy
> > >> > >> > - Releasing pekko 1.1.0 with the latest sbt-osgi (which
> > apparently
> > >> > >> fixes a
> > >> > >> > lot of pain points versus the current osgi used in Pekko 1.0.x)
> > >> would
> > >> > be
> > >> > >> > another nice stretch goal, currently there is one issue with
> > >> duplicate
> > >> > >> > classes but we now have infrastructure set up[6] so that we can
> > >> > properly
> > >> > >> > test such changes.
> > >> > >> >
> > >> > >> > Note that a lot of the underlying reasoning behind my points
> are
> > >> also
> > >> > >> > strategic, i.e. keeping features which can be considered
> critical
> > >> to
> > >> > >> Pekko
> > >> > >> > and/or current Akka users which don't require to much effort
> > >> > (basically
> > >> > >> > anything that gives a reason for people to use/migrate to Pekko
> > >> while
> > >> > >> not
> > >> > >> > breaking the i.e. our bank so to speak). I know that there has
> > >> been a
> > >> > >> push
> > >> > >> > to do things like drop JDK 8, Scala 2.12, osgi etc etc due to
> > death
> > >> > by a
> > >> > >> > thousand cuts but tbh objectively speaking these issues are not
> > >> taking
> > >> > >> up
> > >> > >> > that much time (at least personally by far the largest amount
> of
> > >> time
> > >> > >> spent
> > >> > >> > is just overhead of having to do so many releases and validate
> > >> them,
> > >> > >> really
> > >> > >> > looking forward to the day when we can automate everything with
> > >> > >> > sbt-reproducible-builds/jardiff/create jars in ci etc etc).
> Pekko
> > >> > 2.0.x
> > >> > >> > series is when we can look forward to drop a lot of this
> > "annoying
> > >> > >> > maintenance" stuff and I would actually strongly argue that at
> > the
> > >> > time
> > >> > >> > when we start looking at Pekko 2.0.x we actually get a better
> > idea
> > >> of
> > >> > >> what
> > >> > >> > our Pekko users look like, because as has been shown due to the
> > >> chaos
> > >> > >> > created from the license change very few us had any somewhat
> > >> realistic
> > >> > >> lens
> > >> > >> > as to how the Pekko community (specifically users) look like,
> > i.e.
> > >> > while
> > >> > >> > the OS would **LOVE** to get rid of JDK 1.8 support it just so
> > >> happens
> > >> > >> that
> > >> > >> > a lot of people still need to use JDK 1.8 and even though there
> > are
> > >> > >> reasons
> > >> > >> > to move away from 1.8 evidently they aren't relevant.
> > >> > >> >
> > >> > >> > [1]
> > >> https://lists.apache.org/thread/o494q89hhg64r5nwv4rnq6fsx9zofmny
> > >> > >> > [2] https://github.com/apache/incubator-pekko/pull/305
> > >> > >> > [3] https://github.com/apache/incubator-pekko/pull/765
> > >> > >> > [4] https://github.com/apache/incubator-pekko/pull/587
> > >> > >> > [5] https://github.com/sbt/sbt-multi-release-jar/issues/22
> > >> > >> > [6] https://github.com/apache/incubator-pekko/issues/75
> > >> > >> >
> > >> > >> > On Sun, Nov 5, 2023 at 12:12 PM PJ Fanning <
> fanningpj@apache.org
> > >
> > >> > >> wrote:
> > >> > >> >
> > >> > >> > > The core pekko repo [1] has quite a few changes in its main
> > >> branch
> > >> > >> that
> > >> > >> > > are are targeted at a future 1.1.0 release.
> > >> > >> > >
> > >> > >> > > We haven't really agreed on what to do with the code that was
> > >> > already
> > >> > >> > > deprecated in the Akka era and there is also the issue of the
> > >> > >> ApiMayChange
> > >> > >> > > annotations on some of the APIs.
> > >> > >> > >
> > >> > >> > > There are also some new features that developers want to add.
> > >> > >> > >
> > >> > >> > > We don't have a great deal of developer effort available to
> us.
> > >> > >> > >
> > >> > >> > > I suspect that we need to need to balance the need to release
> > >> some
> > >> > of
> > >> > >> the
> > >> > >> > > 1.1 changes and then maybe try to make another batch of
> changes
> > >> in
> > >> > >> Pekko
> > >> > >> > > 1.2.
> > >> > >> > >
> > >> > >> > > What if we aimed to do a Pekko 1.1.0 release in a few months
> > and
> > >> > said
> > >> > >> that
> > >> > >> > > it was not a Long Term Support release? If we go down this
> > line,
> > >> we
> > >> > >> would
> > >> > >> > > probably want to have a tentative plan as to when a new LTS
> > >> release
> > >> > >> would
> > >> > >> > > happen.
> > >> > >> > >
> > >> > >> > > An example of something that would be useful to release would
> > be
> > >> the
> > >> > >> > > netty4 support. I know that the Apache Flink team would like
> to
> > >> use
> > >> > >> this.
> > >> > >> > >
> > >> > >> > > Alternatively, we could do a Pekko 1.1.0-M1 release. I
> suspect
> > >> that
> > >> > we
> > >> > >> > > would end up with a fair number of these and the M version
> > number
> > >> > >> would
> > >> > >> > > discourage uptake (except for testing).
> > >> > >> > >
> > >> > >> > > What are people's thoughts on the options?
> > >> > >> > >
> > >> > >> > >
> > >> > >> > >
> > >> > >> > > [1] https://github.com/apache/incubator-pekko
> > >> > >> > >
> > >> > >> > >
> > >> >
> ---------------------------------------------------------------------
> > >> > >> > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > >> > >> > > For additional commands, e-mail: dev-help@pekko.apache.org
> > >> > >> > >
> > >> > >> > >
> > >> > >> >
> > >> > >> > --
> > >> > >> >
> > >> > >> > Matthew de Detrich
> > >> > >> >
> > >> > >> > *Aiven Deutschland GmbH*
> > >> > >> >
> > >> > >> > Immanuelkirchstraße 26, 10405 Berlin
> > >> > >> >
> > >> > >> > Alexanderufer 3-7, 10117 Berlin
> > >> > >> >
> > >> > >> > Amtsgericht Charlottenburg, HRB 209739 B
> > >> > >> >
> > >> > >> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > >> > >> >
> > >> > >> > *m:* +491603708037
> > >> > >> >
> > >> > >> > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> > >> > >>
> > >> > >>
> > ---------------------------------------------------------------------
> > >> > >> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > >> > >> For additional commands, e-mail: dev-help@pekko.apache.org
> > >> > >>
> > >> > >>
> > >> > >
> > >> > > --
> > >> > >
> > >> > > Matthew de Detrich
> > >> > >
> > >> > > *Aiven Deutschland GmbH*
> > >> > >
> > >> > > Immanuelkirchstraße 26, 10405 Berlin
> > >> > >
> > >> > > Alexanderufer 3-7, 10117 Berlin
> > >> > >
> > >> > > Amtsgericht Charlottenburg, HRB 209739 B
> > >> > >
> > >> > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > >> > >
> > >> > > *m:* +491603708037
> > >> > >
> > >> > > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> > >> > >
> > >> >
> > >> >
> > >> > --
> > >> >
> > >> > Matthew de Detrich
> > >> >
> > >> > *Aiven Deutschland GmbH*
> > >> >
> > >> > Immanuelkirchstraße 26, 10405 Berlin
> > >> >
> > >> > Alexanderufer 3-7, 10117 Berlin
> > >> >
> > >> > Amtsgericht Charlottenburg, HRB 209739 B
> > >> >
> > >> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > >> >
> > >> > *m:* +491603708037
> > >> >
> > >> > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> > >> >
> > >>
> > >
> > >
> > > --
> > >
> > > Matthew de Detrich
> > >
> > > *Aiven Deutschland GmbH*
> > >
> > > Immanuelkirchstraße 26, 10405 Berlin
> > >
> > > Alexanderufer 3-7, 10117 Berlin
> > >
> > > Amtsgericht Charlottenburg, HRB 209739 B
> > >
> > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > >
> > > *m:* +491603708037
> > >
> > > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> > >
> >
> >
> > --
> >
> > Matthew de Detrich
> >
> > *Aiven Deutschland GmbH*
> >
> > Immanuelkirchstraße 26, 10405 Berlin
> >
> > Alexanderufer 3-7, 10117 Berlin
> >
> > Amtsgericht Charlottenburg, HRB 209739 B
> >
> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> >
> > *m:* +491603708037
> >
> > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> >
>
--
Matthew de Detrich
*Aiven Deutschland GmbH*
Immanuelkirchstraße 26, 10405 Berlin
Alexanderufer 3-7, 10117 Berlin
Amtsgericht Charlottenburg, HRB 209739 B
Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
*m:* +491603708037
*w:* aiven.io *e:* matthew.dedetrich@aiven.io
Re: having non-LTS releases
Posted by kerr <he...@gmail.com>.
Should we support limit the max forkjoinpool in 1.1.x? there is a pending
pr, I think it would be nice to included in.
Virtual thread can limit it with `
-Djdk.virtualThreadScheduler.maxPoolSize=256"`
何品
Matthew de Detrich <ma...@aiven.io.invalid> 于2024年1月15日周一
09:33写道：
> Regarding mult-release JAR support, I did some initial work[1] and I think
> that this
> will have to wait, possible for SBT 2.x since there are fundamental
> limitations in sbt
> to properly support this.
>
> Note that its still technically possible, but in doing so we have to
> statically define
> a set of keys (i.e. SBT SettingKey) for **every** JDK version that we want
> to build
> and since we are already at JDK 21 this can get unwieldy pretty quickly.
>
> [1]
>
> https://github.com/sbt/sbt-multi-release-jar/issues/24#issuecomment-1891156070
>
> On Wed, Jan 10, 2024 at 11:06 AM Matthew de Detrich <
> matthew.dedetrich@aiven.io> wrote:
>
> > So I have some good news for one of the big ticket items listed earlier,
> > Pekko is now using the latest version of sbt-osgi which contains a lot of
> > fixes and
> > improvements, see https://github.com/apache/incubator-pekko/pull/920.
> > This avoids
> > us having to drop sbt-osgi support (doing so is not off the table
> > completely but should
> > be made as a community decision later). Also
> > https://github.com/apache/incubator-pekko/pull/252
> > landed which is important since it's a behavioural change.
> >
> > I would say the only other big item that should be handled before an M1
> > vote is
> > finishing off the inliner changes,
> > https://github.com/apache/incubator-pekko/pull/587
> > and the migration of akka to pekko clusters. A milestone release of these
> > changes
> > will provide ample opportunity for extensive testing to make sure as much
> > as possible
> > that the full release is without issues. I left out multi-release-jar
> > support, my feeling is
> > that this is too big of a change for M1 but It might make sense as an M2
> > or as part of 1.2.x.
> >
> > If there is anything that's left out please mention it.
> >
> > On Sun, Dec 24, 2023 at 7:42 AM kerr <he...@gmail.com> wrote:
> >
> >> +1 for this, IIRC Matthew suggested this kind of release too.
> >> 何品
> >>
> >>
> >> Matthew de Detrich <ma...@aiven.io.invalid> 于2023年12月13日周三
> >> 07:06写道：
> >>
> >> > Apologies for necroing this topic, but there is one other feature I
> >> would
> >> > like to add to the M1
> >> > milestone release which is
> >> > https://github.com/apache/incubator-pekko/pull/252. The reason I
> >> > am pointing out this issue specifically is that it is a breaking
> >> behaviour
> >> > change (all of the
> >> > details are in the PR) so it needs to land for the 1.1.x series,
> ideally
> >> > for M1 so we can figure
> >> > out if there are any behavioural regressions.
> >> >
> >> > On Mon, Nov 6, 2023 at 8:40 PM Matthew de Detrich <
> >> > matthew.dedetrich@aiven.io> wrote:
> >> >
> >> > > > Some of those changes will likely also need backporting for
> >> > > 1.0.x releases.
> >> > >
> >> > > Indeed, the rolling migration from Akka to Pekko clusters is
> actually
> >> a
> >> > > feature for 1.0.x, but because
> >> > > of how its designed (i.e. there is a configuration for the
> >> > sender/receiver
> >> > > address), this feature and
> >> > > configuration also needs to exist for Pekko 1.1.0 otherwise the user
> >> > > experience will be extremely
> >> > > unintuitive.
> >> > >
> >> > > > I don't think a 1.1.0-M0 is warranted. This git tag has code that
> is
> >> > > very similar to Pekko 1.0.1. I don't see the merit in having
> multiple
> >> > > ASF contributors having to review such a release.
> >> > >
> >> > > It trivializes MiMa management which is worth the annoyance of
> doing a
> >> > > release. There really
> >> > > isn't any other way without breaking ASF policy, we basically have
> to
> >> > make
> >> > > a release that is
> >> > > not a "real" release.
> >> > >
> >> > > One thing to note is this doesn't occur that frequently (i.e. M0
> >> > > milestones), i.e. its only on a
> >> > > minor version bump and it can be argued that this release can be
> part
> >> of
> >> > > the formality of
> >> > > when we decide to make a 1.1.x branch, i.e. the community makes a
> >> > > decision/vote that
> >> > > at a certain point in time we are going to bump the minor version
> >> which
> >> > > requires a vote
> >> > > and that some vote is also used for the M0 release.
> >> > >
> >> > > In fact, now that I think/write about it, we really should have a
> >> formal
> >> > > vote when we make a
> >> > > minor version bump because it is a significant change, it shouldn't
> be
> >> > > done at whim (even
> >> > > if its from a PMC)
> >> > >
> >> > > > When I say LTS, I mean what versions will get patches for a long
> >> time.
> >> > > Java releases are a good example. If an org really needs a Java 22
> >> > > feature they can use Java 22 in production - but they are expected
> to
> >> > > upgrade to Java 23, etc. when those versions are released until a
> new
> >> > > Java LTS is released. There are other OSS equivalents. I am not
> >> > > talking about Commercial Support contracts - commercial entities are
> >> > > very welcome to fill this gap - this does not need to relate
> directly
> >> > > to the FOSS releases from the ASF project team.
> >> > >
> >> > > I understand the difference between LTS and commercial contract,
> it's
> >> > just
> >> > > that
> >> > > even the variables for how long the support is, is something that I
> >> don't
> >> > > think
> >> > > we have any ability to estimate concretely now. In summary, in my
> view
> >> > > it's too
> >> > > soon to even be discussing this.
> >> > >
> >> > > > If the consensus is to delay Pekko 1.1 until every candidate
> change
> >> is
> >> > > made - then fine - but this stops users from using features that are
> >> > > ready to try, like the Netty 4 support.
> >> > >
> >> > > As discussed on the github issue[1], this is a non issue. A
> milestone
> >> > > release
> >> > > will cater to anyone who really needs netty4 and as stated, it's
> just
> >> as
> >> > > tested
> >> > > as any other Pekko release is. If people are really desperate for
> >> netty4,
> >> > > then
> >> > > they can use the milestone (I would also note that I haven't seen
> any
> >> > > indication that anyone is begging for netty4 right now).
> >> > >
> >> > > > Since Pekko 1.1.0 full release seems like a long way away, it
> might
> >> be
> >> > > worth considering mechanisms to release the most useful changes
> >> > > earlier - in a way that Pekko 1.0 users can uptake.
> >> > >
> >> > > This is what milestones are for, i.e. they are precisely the
> mechanism
> >> > > to solve this issue. It also solves a host of other issues as
> >> discussed
> >> > > here[2].
> >> > >
> >> > > [1] https://github.com/apache/incubator-pekko/pull/778
> >> > > [2]
> https://lists.apache.org/thread/o494q89hhg64r5nwv4rnq6fsx9zofmny
> >> > >
> >> > > On Sun, Nov 5, 2023 at 10:57 PM PJ Fanning <fa...@gmail.com>
> >> wrote:
> >> > >
> >> > >> I have no objections to the general list of changes that we need
> for
> >> > >> 1.1.0. Some of those changes will likely also need backporting for
> >> > >> 1.0.x releases.
> >> > >>
> >> > >> A 1.1.0-M1 release makes sense. I want to delay it by a week or 2
> >> > >> while we decide what to do about the config logging (recent Akka
> >> CVE).
> >> > >>
> >> > >> I don't think a 1.1.0-M0 is warranted. This git tag has code that
> is
> >> > >> very similar to Pekko 1.0.1. I don't see the merit in having
> multiple
> >> > >> ASF contributors having to review such a release.
> >> > >>
> >> > >> I guess it is a separate conversation but there is a fair degree of
> >> > >> resistance to us dropping support for anything. I think we will
> need
> >> > >> to only drop support if it really makes things much easier for us.
> >> > >> Multi Release Jars seems like a better option than dropping Java 8
> >> > >> support (for instance).
> >> > >>
> >> > >> When I say LTS, I mean what versions will get patches for a long
> >> time.
> >> > >> Java releases are a good example. If an org really needs a Java 22
> >> > >> feature they can use Java 22 in production - but they are expected
> to
> >> > >> upgrade to Java 23, etc. when those versions are released until a
> new
> >> > >> Java LTS is released. There are other OSS equivalents. I am not
> >> > >> talking about Commercial Support contracts - commercial entities
> are
> >> > >> very welcome to fill this gap - this does not need to relate
> directly
> >> > >> to the FOSS releases from the ASF project team.
> >> > >>
> >> > >> If the consensus is to delay Pekko 1.1 until every candidate change
> >> is
> >> > >> made - then fine - but this stops users from using features that
> are
> >> > >> ready to try, like the Netty 4 support.
> >> > >>
> >> > >> Since Pekko 1.1.0 full release seems like a long way away, it might
> >> be
> >> > >> worth considering mechanisms to release the most useful changes
> >> > >> earlier - in a way that Pekko 1.0 users can uptake.
> >> > >>
> >> > >>
> >> > >> On Sun, 5 Nov 2023 at 12:59, Matthew de Detrich
> >> > >> <ma...@aiven.io.invalid> wrote:
> >> > >> >
> >> > >> > So my take on this
> >> > >> >
> >> > >> > - We should do milestones to solve the general problem you are
> >> > alluding
> >> > >> to,
> >> > >> > i.e. the M1 milestone that you suggest that we vote on (we should
> >> also
> >> > >> do
> >> > >> > the M0 milestone which is at the exact moment when a new bump to
> >> minor
> >> > >> > version is done, reasoning why is given in this thread[1]). I
> would
> >> > >> argue
> >> > >> > that doing an M1 now is a good idea and then an M2 once other
> >> critical
> >> > >> > features land (such as inliner which is mentioned in the below
> >> point)
> >> > >> > - There are some critical features that need to be merged before
> a
> >> > >> release
> >> > >> > of 1.1.0 Pekko Core is ever made (and 1.1.0 Pekko core needs to
> be
> >> > >> released
> >> > >> > before any other 1.1.0 releases for the other modules) due to
> >> > technical
> >> > >> > reasons. On the top of my head the critical features so far are
> the
> >> > >> > inliner[2] and rolling update migration of Akka to Pekko
> >> clusters[3].
> >> > I
> >> > >> > think it's achievable to get [2] and [3] done in a few months
> time,
> >> > but
> >> > >> we
> >> > >> > would have to focus on getting it over the line ([2] is already
> >> > "done",
> >> > >> it
> >> > >> > just needs a review and testing in downstream modules, [3] likely
> >> > needs
> >> > >> > more work and most of all testing so that it works as expected).
> >> > >> > - Regarding LTS, I don't think we should entertain the idea now.
> We
> >> > >> have no
> >> > >> > idea of what and how an LTS can work and we don't even have the
> >> > capacity
> >> > >> > for it. It might even be a thing that LTS's are "someone else's"
> >> > problem
> >> > >> > (Pekko is open source after all). I think the most critical thing
> >> is
> >> > >> > sticking to semantic versioning, such an expectation is
> manageable
> >> for
> >> > >> us
> >> > >> > and I would argue is kind of a requirement for large open source
> >> > >> projects
> >> > >> > like Pekko
> >> > >> > - Fixing the manager name [4] should also be fixed for 1.1.0
> >> (actually
> >> > >> if
> >> > >> > anything this should be fixed for 1.0.x branch as well)
> >> > >> > - As kind of a stretch goal, sbt-multi-release-jar support for
> >> > 1.1.0[5]
> >> > >> > would be awesome as it would unblock a **lot** of things while
> also
> >> > >> keeping
> >> > >> > part of the community happy
> >> > >> > - Releasing pekko 1.1.0 with the latest sbt-osgi (which
> apparently
> >> > >> fixes a
> >> > >> > lot of pain points versus the current osgi used in Pekko 1.0.x)
> >> would
> >> > be
> >> > >> > another nice stretch goal, currently there is one issue with
> >> duplicate
> >> > >> > classes but we now have infrastructure set up[6] so that we can
> >> > properly
> >> > >> > test such changes.
> >> > >> >
> >> > >> > Note that a lot of the underlying reasoning behind my points are
> >> also
> >> > >> > strategic, i.e. keeping features which can be considered critical
> >> to
> >> > >> Pekko
> >> > >> > and/or current Akka users which don't require to much effort
> >> > (basically
> >> > >> > anything that gives a reason for people to use/migrate to Pekko
> >> while
> >> > >> not
> >> > >> > breaking the i.e. our bank so to speak). I know that there has
> >> been a
> >> > >> push
> >> > >> > to do things like drop JDK 8, Scala 2.12, osgi etc etc due to
> death
> >> > by a
> >> > >> > thousand cuts but tbh objectively speaking these issues are not
> >> taking
> >> > >> up
> >> > >> > that much time (at least personally by far the largest amount of
> >> time
> >> > >> spent
> >> > >> > is just overhead of having to do so many releases and validate
> >> them,
> >> > >> really
> >> > >> > looking forward to the day when we can automate everything with
> >> > >> > sbt-reproducible-builds/jardiff/create jars in ci etc etc). Pekko
> >> > 2.0.x
> >> > >> > series is when we can look forward to drop a lot of this
> "annoying
> >> > >> > maintenance" stuff and I would actually strongly argue that at
> the
> >> > time
> >> > >> > when we start looking at Pekko 2.0.x we actually get a better
> idea
> >> of
> >> > >> what
> >> > >> > our Pekko users look like, because as has been shown due to the
> >> chaos
> >> > >> > created from the license change very few us had any somewhat
> >> realistic
> >> > >> lens
> >> > >> > as to how the Pekko community (specifically users) look like,
> i.e.
> >> > while
> >> > >> > the OS would **LOVE** to get rid of JDK 1.8 support it just so
> >> happens
> >> > >> that
> >> > >> > a lot of people still need to use JDK 1.8 and even though there
> are
> >> > >> reasons
> >> > >> > to move away from 1.8 evidently they aren't relevant.
> >> > >> >
> >> > >> > [1]
> >> https://lists.apache.org/thread/o494q89hhg64r5nwv4rnq6fsx9zofmny
> >> > >> > [2] https://github.com/apache/incubator-pekko/pull/305
> >> > >> > [3] https://github.com/apache/incubator-pekko/pull/765
> >> > >> > [4] https://github.com/apache/incubator-pekko/pull/587
> >> > >> > [5] https://github.com/sbt/sbt-multi-release-jar/issues/22
> >> > >> > [6] https://github.com/apache/incubator-pekko/issues/75
> >> > >> >
> >> > >> > On Sun, Nov 5, 2023 at 12:12 PM PJ Fanning <fanningpj@apache.org
> >
> >> > >> wrote:
> >> > >> >
> >> > >> > > The core pekko repo [1] has quite a few changes in its main
> >> branch
> >> > >> that
> >> > >> > > are are targeted at a future 1.1.0 release.
> >> > >> > >
> >> > >> > > We haven't really agreed on what to do with the code that was
> >> > already
> >> > >> > > deprecated in the Akka era and there is also the issue of the
> >> > >> ApiMayChange
> >> > >> > > annotations on some of the APIs.
> >> > >> > >
> >> > >> > > There are also some new features that developers want to add.
> >> > >> > >
> >> > >> > > We don't have a great deal of developer effort available to us.
> >> > >> > >
> >> > >> > > I suspect that we need to need to balance the need to release
> >> some
> >> > of
> >> > >> the
> >> > >> > > 1.1 changes and then maybe try to make another batch of changes
> >> in
> >> > >> Pekko
> >> > >> > > 1.2.
> >> > >> > >
> >> > >> > > What if we aimed to do a Pekko 1.1.0 release in a few months
> and
> >> > said
> >> > >> that
> >> > >> > > it was not a Long Term Support release? If we go down this
> line,
> >> we
> >> > >> would
> >> > >> > > probably want to have a tentative plan as to when a new LTS
> >> release
> >> > >> would
> >> > >> > > happen.
> >> > >> > >
> >> > >> > > An example of something that would be useful to release would
> be
> >> the
> >> > >> > > netty4 support. I know that the Apache Flink team would like to
> >> use
> >> > >> this.
> >> > >> > >
> >> > >> > > Alternatively, we could do a Pekko 1.1.0-M1 release. I suspect
> >> that
> >> > we
> >> > >> > > would end up with a fair number of these and the M version
> number
> >> > >> would
> >> > >> > > discourage uptake (except for testing).
> >> > >> > >
> >> > >> > > What are people's thoughts on the options?
> >> > >> > >
> >> > >> > >
> >> > >> > >
> >> > >> > > [1] https://github.com/apache/incubator-pekko
> >> > >> > >
> >> > >> > >
> >> > ---------------------------------------------------------------------
> >> > >> > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> >> > >> > > For additional commands, e-mail: dev-help@pekko.apache.org
> >> > >> > >
> >> > >> > >
> >> > >> >
> >> > >> > --
> >> > >> >
> >> > >> > Matthew de Detrich
> >> > >> >
> >> > >> > *Aiven Deutschland GmbH*
> >> > >> >
> >> > >> > Immanuelkirchstraße 26, 10405 Berlin
> >> > >> >
> >> > >> > Alexanderufer 3-7, 10117 Berlin
> >> > >> >
> >> > >> > Amtsgericht Charlottenburg, HRB 209739 B
> >> > >> >
> >> > >> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> >> > >> >
> >> > >> > *m:* +491603708037
> >> > >> >
> >> > >> > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> >> > >>
> >> > >>
> ---------------------------------------------------------------------
> >> > >> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> >> > >> For additional commands, e-mail: dev-help@pekko.apache.org
> >> > >>
> >> > >>
> >> > >
> >> > > --
> >> > >
> >> > > Matthew de Detrich
> >> > >
> >> > > *Aiven Deutschland GmbH*
> >> > >
> >> > > Immanuelkirchstraße 26, 10405 Berlin
> >> > >
> >> > > Alexanderufer 3-7, 10117 Berlin
> >> > >
> >> > > Amtsgericht Charlottenburg, HRB 209739 B
> >> > >
> >> > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> >> > >
> >> > > *m:* +491603708037
> >> > >
> >> > > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> >> > >
> >> >
> >> >
> >> > --
> >> >
> >> > Matthew de Detrich
> >> >
> >> > *Aiven Deutschland GmbH*
> >> >
> >> > Immanuelkirchstraße 26, 10405 Berlin
> >> >
> >> > Alexanderufer 3-7, 10117 Berlin
> >> >
> >> > Amtsgericht Charlottenburg, HRB 209739 B
> >> >
> >> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> >> >
> >> > *m:* +491603708037
> >> >
> >> > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> >> >
> >>
> >
> >
> > --
> >
> > Matthew de Detrich
> >
> > *Aiven Deutschland GmbH*
> >
> > Immanuelkirchstraße 26, 10405 Berlin
> >
> > Alexanderufer 3-7, 10117 Berlin
> >
> > Amtsgericht Charlottenburg, HRB 209739 B
> >
> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> >
> > *m:* +491603708037
> >
> > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> >
>
>
> --
>
> Matthew de Detrich
>
> *Aiven Deutschland GmbH*
>
> Immanuelkirchstraße 26, 10405 Berlin
>
> Alexanderufer 3-7, 10117 Berlin
>
> Amtsgericht Charlottenburg, HRB 209739 B
>
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
>
> *m:* +491603708037
>
> *w:* aiven.io *e:* matthew.dedetrich@aiven.io
>
Re: having non-LTS releases
Posted by Matthew de Detrich <ma...@aiven.io.INVALID>.
Regarding mult-release JAR support, I did some initial work[1] and I think
that this
will have to wait, possible for SBT 2.x since there are fundamental
limitations in sbt
to properly support this.
Note that its still technically possible, but in doing so we have to
statically define
a set of keys (i.e. SBT SettingKey) for **every** JDK version that we want
to build
and since we are already at JDK 21 this can get unwieldy pretty quickly.
[1]
https://github.com/sbt/sbt-multi-release-jar/issues/24#issuecomment-1891156070
On Wed, Jan 10, 2024 at 11:06 AM Matthew de Detrich <
matthew.dedetrich@aiven.io> wrote:
> So I have some good news for one of the big ticket items listed earlier,
> Pekko is now using the latest version of sbt-osgi which contains a lot of
> fixes and
> improvements, see https://github.com/apache/incubator-pekko/pull/920.
> This avoids
> us having to drop sbt-osgi support (doing so is not off the table
> completely but should
> be made as a community decision later). Also
> https://github.com/apache/incubator-pekko/pull/252
> landed which is important since it's a behavioural change.
>
> I would say the only other big item that should be handled before an M1
> vote is
> finishing off the inliner changes,
> https://github.com/apache/incubator-pekko/pull/587
> and the migration of akka to pekko clusters. A milestone release of these
> changes
> will provide ample opportunity for extensive testing to make sure as much
> as possible
> that the full release is without issues. I left out multi-release-jar
> support, my feeling is
> that this is too big of a change for M1 but It might make sense as an M2
> or as part of 1.2.x.
>
> If there is anything that's left out please mention it.
>
> On Sun, Dec 24, 2023 at 7:42 AM kerr <he...@gmail.com> wrote:
>
>> +1 for this, IIRC Matthew suggested this kind of release too.
>> 何品
>>
>>
>> Matthew de Detrich <ma...@aiven.io.invalid> 于2023年12月13日周三
>> 07:06写道：
>>
>> > Apologies for necroing this topic, but there is one other feature I
>> would
>> > like to add to the M1
>> > milestone release which is
>> > https://github.com/apache/incubator-pekko/pull/252. The reason I
>> > am pointing out this issue specifically is that it is a breaking
>> behaviour
>> > change (all of the
>> > details are in the PR) so it needs to land for the 1.1.x series, ideally
>> > for M1 so we can figure
>> > out if there are any behavioural regressions.
>> >
>> > On Mon, Nov 6, 2023 at 8:40 PM Matthew de Detrich <
>> > matthew.dedetrich@aiven.io> wrote:
>> >
>> > > > Some of those changes will likely also need backporting for
>> > > 1.0.x releases.
>> > >
>> > > Indeed, the rolling migration from Akka to Pekko clusters is actually
>> a
>> > > feature for 1.0.x, but because
>> > > of how its designed (i.e. there is a configuration for the
>> > sender/receiver
>> > > address), this feature and
>> > > configuration also needs to exist for Pekko 1.1.0 otherwise the user
>> > > experience will be extremely
>> > > unintuitive.
>> > >
>> > > > I don't think a 1.1.0-M0 is warranted. This git tag has code that is
>> > > very similar to Pekko 1.0.1. I don't see the merit in having multiple
>> > > ASF contributors having to review such a release.
>> > >
>> > > It trivializes MiMa management which is worth the annoyance of doing a
>> > > release. There really
>> > > isn't any other way without breaking ASF policy, we basically have to
>> > make
>> > > a release that is
>> > > not a "real" release.
>> > >
>> > > One thing to note is this doesn't occur that frequently (i.e. M0
>> > > milestones), i.e. its only on a
>> > > minor version bump and it can be argued that this release can be part
>> of
>> > > the formality of
>> > > when we decide to make a 1.1.x branch, i.e. the community makes a
>> > > decision/vote that
>> > > at a certain point in time we are going to bump the minor version
>> which
>> > > requires a vote
>> > > and that some vote is also used for the M0 release.
>> > >
>> > > In fact, now that I think/write about it, we really should have a
>> formal
>> > > vote when we make a
>> > > minor version bump because it is a significant change, it shouldn't be
>> > > done at whim (even
>> > > if its from a PMC)
>> > >
>> > > > When I say LTS, I mean what versions will get patches for a long
>> time.
>> > > Java releases are a good example. If an org really needs a Java 22
>> > > feature they can use Java 22 in production - but they are expected to
>> > > upgrade to Java 23, etc. when those versions are released until a new
>> > > Java LTS is released. There are other OSS equivalents. I am not
>> > > talking about Commercial Support contracts - commercial entities are
>> > > very welcome to fill this gap - this does not need to relate directly
>> > > to the FOSS releases from the ASF project team.
>> > >
>> > > I understand the difference between LTS and commercial contract, it's
>> > just
>> > > that
>> > > even the variables for how long the support is, is something that I
>> don't
>> > > think
>> > > we have any ability to estimate concretely now. In summary, in my view
>> > > it's too
>> > > soon to even be discussing this.
>> > >
>> > > > If the consensus is to delay Pekko 1.1 until every candidate change
>> is
>> > > made - then fine - but this stops users from using features that are
>> > > ready to try, like the Netty 4 support.
>> > >
>> > > As discussed on the github issue[1], this is a non issue. A milestone
>> > > release
>> > > will cater to anyone who really needs netty4 and as stated, it's just
>> as
>> > > tested
>> > > as any other Pekko release is. If people are really desperate for
>> netty4,
>> > > then
>> > > they can use the milestone (I would also note that I haven't seen any
>> > > indication that anyone is begging for netty4 right now).
>> > >
>> > > > Since Pekko 1.1.0 full release seems like a long way away, it might
>> be
>> > > worth considering mechanisms to release the most useful changes
>> > > earlier - in a way that Pekko 1.0 users can uptake.
>> > >
>> > > This is what milestones are for, i.e. they are precisely the mechanism
>> > > to solve this issue. It also solves a host of other issues as
>> discussed
>> > > here[2].
>> > >
>> > > [1] https://github.com/apache/incubator-pekko/pull/778
>> > > [2] https://lists.apache.org/thread/o494q89hhg64r5nwv4rnq6fsx9zofmny
>> > >
>> > > On Sun, Nov 5, 2023 at 10:57 PM PJ Fanning <fa...@gmail.com>
>> wrote:
>> > >
>> > >> I have no objections to the general list of changes that we need for
>> > >> 1.1.0. Some of those changes will likely also need backporting for
>> > >> 1.0.x releases.
>> > >>
>> > >> A 1.1.0-M1 release makes sense. I want to delay it by a week or 2
>> > >> while we decide what to do about the config logging (recent Akka
>> CVE).
>> > >>
>> > >> I don't think a 1.1.0-M0 is warranted. This git tag has code that is
>> > >> very similar to Pekko 1.0.1. I don't see the merit in having multiple
>> > >> ASF contributors having to review such a release.
>> > >>
>> > >> I guess it is a separate conversation but there is a fair degree of
>> > >> resistance to us dropping support for anything. I think we will need
>> > >> to only drop support if it really makes things much easier for us.
>> > >> Multi Release Jars seems like a better option than dropping Java 8
>> > >> support (for instance).
>> > >>
>> > >> When I say LTS, I mean what versions will get patches for a long
>> time.
>> > >> Java releases are a good example. If an org really needs a Java 22
>> > >> feature they can use Java 22 in production - but they are expected to
>> > >> upgrade to Java 23, etc. when those versions are released until a new
>> > >> Java LTS is released. There are other OSS equivalents. I am not
>> > >> talking about Commercial Support contracts - commercial entities are
>> > >> very welcome to fill this gap - this does not need to relate directly
>> > >> to the FOSS releases from the ASF project team.
>> > >>
>> > >> If the consensus is to delay Pekko 1.1 until every candidate change
>> is
>> > >> made - then fine - but this stops users from using features that are
>> > >> ready to try, like the Netty 4 support.
>> > >>
>> > >> Since Pekko 1.1.0 full release seems like a long way away, it might
>> be
>> > >> worth considering mechanisms to release the most useful changes
>> > >> earlier - in a way that Pekko 1.0 users can uptake.
>> > >>
>> > >>
>> > >> On Sun, 5 Nov 2023 at 12:59, Matthew de Detrich
>> > >> <ma...@aiven.io.invalid> wrote:
>> > >> >
>> > >> > So my take on this
>> > >> >
>> > >> > - We should do milestones to solve the general problem you are
>> > alluding
>> > >> to,
>> > >> > i.e. the M1 milestone that you suggest that we vote on (we should
>> also
>> > >> do
>> > >> > the M0 milestone which is at the exact moment when a new bump to
>> minor
>> > >> > version is done, reasoning why is given in this thread[1]). I would
>> > >> argue
>> > >> > that doing an M1 now is a good idea and then an M2 once other
>> critical
>> > >> > features land (such as inliner which is mentioned in the below
>> point)
>> > >> > - There are some critical features that need to be merged before a
>> > >> release
>> > >> > of 1.1.0 Pekko Core is ever made (and 1.1.0 Pekko core needs to be
>> > >> released
>> > >> > before any other 1.1.0 releases for the other modules) due to
>> > technical
>> > >> > reasons. On the top of my head the critical features so far are the
>> > >> > inliner[2] and rolling update migration of Akka to Pekko
>> clusters[3].
>> > I
>> > >> > think it's achievable to get [2] and [3] done in a few months time,
>> > but
>> > >> we
>> > >> > would have to focus on getting it over the line ([2] is already
>> > "done",
>> > >> it
>> > >> > just needs a review and testing in downstream modules, [3] likely
>> > needs
>> > >> > more work and most of all testing so that it works as expected).
>> > >> > - Regarding LTS, I don't think we should entertain the idea now. We
>> > >> have no
>> > >> > idea of what and how an LTS can work and we don't even have the
>> > capacity
>> > >> > for it. It might even be a thing that LTS's are "someone else's"
>> > problem
>> > >> > (Pekko is open source after all). I think the most critical thing
>> is
>> > >> > sticking to semantic versioning, such an expectation is manageable
>> for
>> > >> us
>> > >> > and I would argue is kind of a requirement for large open source
>> > >> projects
>> > >> > like Pekko
>> > >> > - Fixing the manager name [4] should also be fixed for 1.1.0
>> (actually
>> > >> if
>> > >> > anything this should be fixed for 1.0.x branch as well)
>> > >> > - As kind of a stretch goal, sbt-multi-release-jar support for
>> > 1.1.0[5]
>> > >> > would be awesome as it would unblock a **lot** of things while also
>> > >> keeping
>> > >> > part of the community happy
>> > >> > - Releasing pekko 1.1.0 with the latest sbt-osgi (which apparently
>> > >> fixes a
>> > >> > lot of pain points versus the current osgi used in Pekko 1.0.x)
>> would
>> > be
>> > >> > another nice stretch goal, currently there is one issue with
>> duplicate
>> > >> > classes but we now have infrastructure set up[6] so that we can
>> > properly
>> > >> > test such changes.
>> > >> >
>> > >> > Note that a lot of the underlying reasoning behind my points are
>> also
>> > >> > strategic, i.e. keeping features which can be considered critical
>> to
>> > >> Pekko
>> > >> > and/or current Akka users which don't require to much effort
>> > (basically
>> > >> > anything that gives a reason for people to use/migrate to Pekko
>> while
>> > >> not
>> > >> > breaking the i.e. our bank so to speak). I know that there has
>> been a
>> > >> push
>> > >> > to do things like drop JDK 8, Scala 2.12, osgi etc etc due to death
>> > by a
>> > >> > thousand cuts but tbh objectively speaking these issues are not
>> taking
>> > >> up
>> > >> > that much time (at least personally by far the largest amount of
>> time
>> > >> spent
>> > >> > is just overhead of having to do so many releases and validate
>> them,
>> > >> really
>> > >> > looking forward to the day when we can automate everything with
>> > >> > sbt-reproducible-builds/jardiff/create jars in ci etc etc). Pekko
>> > 2.0.x
>> > >> > series is when we can look forward to drop a lot of this "annoying
>> > >> > maintenance" stuff and I would actually strongly argue that at the
>> > time
>> > >> > when we start looking at Pekko 2.0.x we actually get a better idea
>> of
>> > >> what
>> > >> > our Pekko users look like, because as has been shown due to the
>> chaos
>> > >> > created from the license change very few us had any somewhat
>> realistic
>> > >> lens
>> > >> > as to how the Pekko community (specifically users) look like, i.e.
>> > while
>> > >> > the OS would **LOVE** to get rid of JDK 1.8 support it just so
>> happens
>> > >> that
>> > >> > a lot of people still need to use JDK 1.8 and even though there are
>> > >> reasons
>> > >> > to move away from 1.8 evidently they aren't relevant.
>> > >> >
>> > >> > [1]
>> https://lists.apache.org/thread/o494q89hhg64r5nwv4rnq6fsx9zofmny
>> > >> > [2] https://github.com/apache/incubator-pekko/pull/305
>> > >> > [3] https://github.com/apache/incubator-pekko/pull/765
>> > >> > [4] https://github.com/apache/incubator-pekko/pull/587
>> > >> > [5] https://github.com/sbt/sbt-multi-release-jar/issues/22
>> > >> > [6] https://github.com/apache/incubator-pekko/issues/75
>> > >> >
>> > >> > On Sun, Nov 5, 2023 at 12:12 PM PJ Fanning <fa...@apache.org>
>> > >> wrote:
>> > >> >
>> > >> > > The core pekko repo [1] has quite a few changes in its main
>> branch
>> > >> that
>> > >> > > are are targeted at a future 1.1.0 release.
>> > >> > >
>> > >> > > We haven't really agreed on what to do with the code that was
>> > already
>> > >> > > deprecated in the Akka era and there is also the issue of the
>> > >> ApiMayChange
>> > >> > > annotations on some of the APIs.
>> > >> > >
>> > >> > > There are also some new features that developers want to add.
>> > >> > >
>> > >> > > We don't have a great deal of developer effort available to us.
>> > >> > >
>> > >> > > I suspect that we need to need to balance the need to release
>> some
>> > of
>> > >> the
>> > >> > > 1.1 changes and then maybe try to make another batch of changes
>> in
>> > >> Pekko
>> > >> > > 1.2.
>> > >> > >
>> > >> > > What if we aimed to do a Pekko 1.1.0 release in a few months and
>> > said
>> > >> that
>> > >> > > it was not a Long Term Support release? If we go down this line,
>> we
>> > >> would
>> > >> > > probably want to have a tentative plan as to when a new LTS
>> release
>> > >> would
>> > >> > > happen.
>> > >> > >
>> > >> > > An example of something that would be useful to release would be
>> the
>> > >> > > netty4 support. I know that the Apache Flink team would like to
>> use
>> > >> this.
>> > >> > >
>> > >> > > Alternatively, we could do a Pekko 1.1.0-M1 release. I suspect
>> that
>> > we
>> > >> > > would end up with a fair number of these and the M version number
>> > >> would
>> > >> > > discourage uptake (except for testing).
>> > >> > >
>> > >> > > What are people's thoughts on the options?
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> > > [1] https://github.com/apache/incubator-pekko
>> > >> > >
>> > >> > >
>> > ---------------------------------------------------------------------
>> > >> > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
>> > >> > > For additional commands, e-mail: dev-help@pekko.apache.org
>> > >> > >
>> > >> > >
>> > >> >
>> > >> > --
>> > >> >
>> > >> > Matthew de Detrich
>> > >> >
>> > >> > *Aiven Deutschland GmbH*
>> > >> >
>> > >> > Immanuelkirchstraße 26, 10405 Berlin
>> > >> >
>> > >> > Alexanderufer 3-7, 10117 Berlin
>> > >> >
>> > >> > Amtsgericht Charlottenburg, HRB 209739 B
>> > >> >
>> > >> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
>> > >> >
>> > >> > *m:* +491603708037
>> > >> >
>> > >> > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
>> > >>
>> > >> ---------------------------------------------------------------------
>> > >> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
>> > >> For additional commands, e-mail: dev-help@pekko.apache.org
>> > >>
>> > >>
>> > >
>> > > --
>> > >
>> > > Matthew de Detrich
>> > >
>> > > *Aiven Deutschland GmbH*
>> > >
>> > > Immanuelkirchstraße 26, 10405 Berlin
>> > >
>> > > Alexanderufer 3-7, 10117 Berlin
>> > >
>> > > Amtsgericht Charlottenburg, HRB 209739 B
>> > >
>> > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
>> > >
>> > > *m:* +491603708037
>> > >
>> > > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
>> > >
>> >
>> >
>> > --
>> >
>> > Matthew de Detrich
>> >
>> > *Aiven Deutschland GmbH*
>> >
>> > Immanuelkirchstraße 26, 10405 Berlin
>> >
>> > Alexanderufer 3-7, 10117 Berlin
>> >
>> > Amtsgericht Charlottenburg, HRB 209739 B
>> >
>> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
>> >
>> > *m:* +491603708037
>> >
>> > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
>> >
>>
>
>
> --
>
> Matthew de Detrich
>
> *Aiven Deutschland GmbH*
>
> Immanuelkirchstraße 26, 10405 Berlin
>
> Alexanderufer 3-7, 10117 Berlin
>
> Amtsgericht Charlottenburg, HRB 209739 B
>
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
>
> *m:* +491603708037
>
> *w:* aiven.io *e:* matthew.dedetrich@aiven.io
>
--
Matthew de Detrich
*Aiven Deutschland GmbH*
Immanuelkirchstraße 26, 10405 Berlin
Alexanderufer 3-7, 10117 Berlin
Amtsgericht Charlottenburg, HRB 209739 B
Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
*m:* +491603708037
*w:* aiven.io *e:* matthew.dedetrich@aiven.io
Re: having non-LTS releases
Posted by kerr <he...@gmail.com>.
I would like to finish add `mapWithResource` to pekko in M1 too, I think I
can finish it this weekend.
何品
Matthew de Detrich <ma...@aiven.io.invalid> 于2024年1月10日周三
08:08写道：
> So I have some good news for one of the big ticket items listed earlier,
> Pekko is now using the latest version of sbt-osgi which contains a lot of
> fixes and
> improvements, see https://github.com/apache/incubator-pekko/pull/920. This
> avoids
> us having to drop sbt-osgi support (doing so is not off the table
> completely but should
> be made as a community decision later). Also
> https://github.com/apache/incubator-pekko/pull/252
> landed which is important since it's a behavioural change.
>
> I would say the only other big item that should be handled before an M1
> vote is
> finishing off the inliner changes,
> https://github.com/apache/incubator-pekko/pull/587
> and the migration of akka to pekko clusters. A milestone release of these
> changes
> will provide ample opportunity for extensive testing to make sure as much
> as possible
> that the full release is without issues. I left out multi-release-jar
> support, my feeling is
> that this is too big of a change for M1 but It might make sense as an M2
> or as part of 1.2.x.
>
> If there is anything that's left out please mention it.
>
> On Sun, Dec 24, 2023 at 7:42 AM kerr <he...@gmail.com> wrote:
>
> > +1 for this, IIRC Matthew suggested this kind of release too.
> > 何品
> >
> >
> > Matthew de Detrich <ma...@aiven.io.invalid> 于2023年12月13日周三
> > 07:06写道：
> >
> > > Apologies for necroing this topic, but there is one other feature I
> would
> > > like to add to the M1
> > > milestone release which is
> > > https://github.com/apache/incubator-pekko/pull/252. The reason I
> > > am pointing out this issue specifically is that it is a breaking
> > behaviour
> > > change (all of the
> > > details are in the PR) so it needs to land for the 1.1.x series,
> ideally
> > > for M1 so we can figure
> > > out if there are any behavioural regressions.
> > >
> > > On Mon, Nov 6, 2023 at 8:40 PM Matthew de Detrich <
> > > matthew.dedetrich@aiven.io> wrote:
> > >
> > > > > Some of those changes will likely also need backporting for
> > > > 1.0.x releases.
> > > >
> > > > Indeed, the rolling migration from Akka to Pekko clusters is
> actually a
> > > > feature for 1.0.x, but because
> > > > of how its designed (i.e. there is a configuration for the
> > > sender/receiver
> > > > address), this feature and
> > > > configuration also needs to exist for Pekko 1.1.0 otherwise the user
> > > > experience will be extremely
> > > > unintuitive.
> > > >
> > > > > I don't think a 1.1.0-M0 is warranted. This git tag has code that
> is
> > > > very similar to Pekko 1.0.1. I don't see the merit in having multiple
> > > > ASF contributors having to review such a release.
> > > >
> > > > It trivializes MiMa management which is worth the annoyance of doing
> a
> > > > release. There really
> > > > isn't any other way without breaking ASF policy, we basically have to
> > > make
> > > > a release that is
> > > > not a "real" release.
> > > >
> > > > One thing to note is this doesn't occur that frequently (i.e. M0
> > > > milestones), i.e. its only on a
> > > > minor version bump and it can be argued that this release can be part
> > of
> > > > the formality of
> > > > when we decide to make a 1.1.x branch, i.e. the community makes a
> > > > decision/vote that
> > > > at a certain point in time we are going to bump the minor version
> which
> > > > requires a vote
> > > > and that some vote is also used for the M0 release.
> > > >
> > > > In fact, now that I think/write about it, we really should have a
> > formal
> > > > vote when we make a
> > > > minor version bump because it is a significant change, it shouldn't
> be
> > > > done at whim (even
> > > > if its from a PMC)
> > > >
> > > > > When I say LTS, I mean what versions will get patches for a long
> > time.
> > > > Java releases are a good example. If an org really needs a Java 22
> > > > feature they can use Java 22 in production - but they are expected to
> > > > upgrade to Java 23, etc. when those versions are released until a new
> > > > Java LTS is released. There are other OSS equivalents. I am not
> > > > talking about Commercial Support contracts - commercial entities are
> > > > very welcome to fill this gap - this does not need to relate directly
> > > > to the FOSS releases from the ASF project team.
> > > >
> > > > I understand the difference between LTS and commercial contract, it's
> > > just
> > > > that
> > > > even the variables for how long the support is, is something that I
> > don't
> > > > think
> > > > we have any ability to estimate concretely now. In summary, in my
> view
> > > > it's too
> > > > soon to even be discussing this.
> > > >
> > > > > If the consensus is to delay Pekko 1.1 until every candidate change
> > is
> > > > made - then fine - but this stops users from using features that are
> > > > ready to try, like the Netty 4 support.
> > > >
> > > > As discussed on the github issue[1], this is a non issue. A milestone
> > > > release
> > > > will cater to anyone who really needs netty4 and as stated, it's just
> > as
> > > > tested
> > > > as any other Pekko release is. If people are really desperate for
> > netty4,
> > > > then
> > > > they can use the milestone (I would also note that I haven't seen any
> > > > indication that anyone is begging for netty4 right now).
> > > >
> > > > > Since Pekko 1.1.0 full release seems like a long way away, it might
> > be
> > > > worth considering mechanisms to release the most useful changes
> > > > earlier - in a way that Pekko 1.0 users can uptake.
> > > >
> > > > This is what milestones are for, i.e. they are precisely the
> mechanism
> > > > to solve this issue. It also solves a host of other issues as
> discussed
> > > > here[2].
> > > >
> > > > [1] https://github.com/apache/incubator-pekko/pull/778
> > > > [2] https://lists.apache.org/thread/o494q89hhg64r5nwv4rnq6fsx9zofmny
> > > >
> > > > On Sun, Nov 5, 2023 at 10:57 PM PJ Fanning <fa...@gmail.com>
> > wrote:
> > > >
> > > >> I have no objections to the general list of changes that we need for
> > > >> 1.1.0. Some of those changes will likely also need backporting for
> > > >> 1.0.x releases.
> > > >>
> > > >> A 1.1.0-M1 release makes sense. I want to delay it by a week or 2
> > > >> while we decide what to do about the config logging (recent Akka
> CVE).
> > > >>
> > > >> I don't think a 1.1.0-M0 is warranted. This git tag has code that is
> > > >> very similar to Pekko 1.0.1. I don't see the merit in having
> multiple
> > > >> ASF contributors having to review such a release.
> > > >>
> > > >> I guess it is a separate conversation but there is a fair degree of
> > > >> resistance to us dropping support for anything. I think we will need
> > > >> to only drop support if it really makes things much easier for us.
> > > >> Multi Release Jars seems like a better option than dropping Java 8
> > > >> support (for instance).
> > > >>
> > > >> When I say LTS, I mean what versions will get patches for a long
> time.
> > > >> Java releases are a good example. If an org really needs a Java 22
> > > >> feature they can use Java 22 in production - but they are expected
> to
> > > >> upgrade to Java 23, etc. when those versions are released until a
> new
> > > >> Java LTS is released. There are other OSS equivalents. I am not
> > > >> talking about Commercial Support contracts - commercial entities are
> > > >> very welcome to fill this gap - this does not need to relate
> directly
> > > >> to the FOSS releases from the ASF project team.
> > > >>
> > > >> If the consensus is to delay Pekko 1.1 until every candidate change
> is
> > > >> made - then fine - but this stops users from using features that are
> > > >> ready to try, like the Netty 4 support.
> > > >>
> > > >> Since Pekko 1.1.0 full release seems like a long way away, it might
> be
> > > >> worth considering mechanisms to release the most useful changes
> > > >> earlier - in a way that Pekko 1.0 users can uptake.
> > > >>
> > > >>
> > > >> On Sun, 5 Nov 2023 at 12:59, Matthew de Detrich
> > > >> <ma...@aiven.io.invalid> wrote:
> > > >> >
> > > >> > So my take on this
> > > >> >
> > > >> > - We should do milestones to solve the general problem you are
> > > alluding
> > > >> to,
> > > >> > i.e. the M1 milestone that you suggest that we vote on (we should
> > also
> > > >> do
> > > >> > the M0 milestone which is at the exact moment when a new bump to
> > minor
> > > >> > version is done, reasoning why is given in this thread[1]). I
> would
> > > >> argue
> > > >> > that doing an M1 now is a good idea and then an M2 once other
> > critical
> > > >> > features land (such as inliner which is mentioned in the below
> > point)
> > > >> > - There are some critical features that need to be merged before a
> > > >> release
> > > >> > of 1.1.0 Pekko Core is ever made (and 1.1.0 Pekko core needs to be
> > > >> released
> > > >> > before any other 1.1.0 releases for the other modules) due to
> > > technical
> > > >> > reasons. On the top of my head the critical features so far are
> the
> > > >> > inliner[2] and rolling update migration of Akka to Pekko
> > clusters[3].
> > > I
> > > >> > think it's achievable to get [2] and [3] done in a few months
> time,
> > > but
> > > >> we
> > > >> > would have to focus on getting it over the line ([2] is already
> > > "done",
> > > >> it
> > > >> > just needs a review and testing in downstream modules, [3] likely
> > > needs
> > > >> > more work and most of all testing so that it works as expected).
> > > >> > - Regarding LTS, I don't think we should entertain the idea now.
> We
> > > >> have no
> > > >> > idea of what and how an LTS can work and we don't even have the
> > > capacity
> > > >> > for it. It might even be a thing that LTS's are "someone else's"
> > > problem
> > > >> > (Pekko is open source after all). I think the most critical thing
> is
> > > >> > sticking to semantic versioning, such an expectation is manageable
> > for
> > > >> us
> > > >> > and I would argue is kind of a requirement for large open source
> > > >> projects
> > > >> > like Pekko
> > > >> > - Fixing the manager name [4] should also be fixed for 1.1.0
> > (actually
> > > >> if
> > > >> > anything this should be fixed for 1.0.x branch as well)
> > > >> > - As kind of a stretch goal, sbt-multi-release-jar support for
> > > 1.1.0[5]
> > > >> > would be awesome as it would unblock a **lot** of things while
> also
> > > >> keeping
> > > >> > part of the community happy
> > > >> > - Releasing pekko 1.1.0 with the latest sbt-osgi (which apparently
> > > >> fixes a
> > > >> > lot of pain points versus the current osgi used in Pekko 1.0.x)
> > would
> > > be
> > > >> > another nice stretch goal, currently there is one issue with
> > duplicate
> > > >> > classes but we now have infrastructure set up[6] so that we can
> > > properly
> > > >> > test such changes.
> > > >> >
> > > >> > Note that a lot of the underlying reasoning behind my points are
> > also
> > > >> > strategic, i.e. keeping features which can be considered critical
> to
> > > >> Pekko
> > > >> > and/or current Akka users which don't require to much effort
> > > (basically
> > > >> > anything that gives a reason for people to use/migrate to Pekko
> > while
> > > >> not
> > > >> > breaking the i.e. our bank so to speak). I know that there has
> been
> > a
> > > >> push
> > > >> > to do things like drop JDK 8, Scala 2.12, osgi etc etc due to
> death
> > > by a
> > > >> > thousand cuts but tbh objectively speaking these issues are not
> > taking
> > > >> up
> > > >> > that much time (at least personally by far the largest amount of
> > time
> > > >> spent
> > > >> > is just overhead of having to do so many releases and validate
> them,
> > > >> really
> > > >> > looking forward to the day when we can automate everything with
> > > >> > sbt-reproducible-builds/jardiff/create jars in ci etc etc). Pekko
> > > 2.0.x
> > > >> > series is when we can look forward to drop a lot of this "annoying
> > > >> > maintenance" stuff and I would actually strongly argue that at the
> > > time
> > > >> > when we start looking at Pekko 2.0.x we actually get a better idea
> > of
> > > >> what
> > > >> > our Pekko users look like, because as has been shown due to the
> > chaos
> > > >> > created from the license change very few us had any somewhat
> > realistic
> > > >> lens
> > > >> > as to how the Pekko community (specifically users) look like, i.e.
> > > while
> > > >> > the OS would **LOVE** to get rid of JDK 1.8 support it just so
> > happens
> > > >> that
> > > >> > a lot of people still need to use JDK 1.8 and even though there
> are
> > > >> reasons
> > > >> > to move away from 1.8 evidently they aren't relevant.
> > > >> >
> > > >> > [1]
> > https://lists.apache.org/thread/o494q89hhg64r5nwv4rnq6fsx9zofmny
> > > >> > [2] https://github.com/apache/incubator-pekko/pull/305
> > > >> > [3] https://github.com/apache/incubator-pekko/pull/765
> > > >> > [4] https://github.com/apache/incubator-pekko/pull/587
> > > >> > [5] https://github.com/sbt/sbt-multi-release-jar/issues/22
> > > >> > [6] https://github.com/apache/incubator-pekko/issues/75
> > > >> >
> > > >> > On Sun, Nov 5, 2023 at 12:12 PM PJ Fanning <fa...@apache.org>
> > > >> wrote:
> > > >> >
> > > >> > > The core pekko repo [1] has quite a few changes in its main
> branch
> > > >> that
> > > >> > > are are targeted at a future 1.1.0 release.
> > > >> > >
> > > >> > > We haven't really agreed on what to do with the code that was
> > > already
> > > >> > > deprecated in the Akka era and there is also the issue of the
> > > >> ApiMayChange
> > > >> > > annotations on some of the APIs.
> > > >> > >
> > > >> > > There are also some new features that developers want to add.
> > > >> > >
> > > >> > > We don't have a great deal of developer effort available to us.
> > > >> > >
> > > >> > > I suspect that we need to need to balance the need to release
> some
> > > of
> > > >> the
> > > >> > > 1.1 changes and then maybe try to make another batch of changes
> in
> > > >> Pekko
> > > >> > > 1.2.
> > > >> > >
> > > >> > > What if we aimed to do a Pekko 1.1.0 release in a few months and
> > > said
> > > >> that
> > > >> > > it was not a Long Term Support release? If we go down this line,
> > we
> > > >> would
> > > >> > > probably want to have a tentative plan as to when a new LTS
> > release
> > > >> would
> > > >> > > happen.
> > > >> > >
> > > >> > > An example of something that would be useful to release would be
> > the
> > > >> > > netty4 support. I know that the Apache Flink team would like to
> > use
> > > >> this.
> > > >> > >
> > > >> > > Alternatively, we could do a Pekko 1.1.0-M1 release. I suspect
> > that
> > > we
> > > >> > > would end up with a fair number of these and the M version
> number
> > > >> would
> > > >> > > discourage uptake (except for testing).
> > > >> > >
> > > >> > > What are people's thoughts on the options?
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > [1] https://github.com/apache/incubator-pekko
> > > >> > >
> > > >> > >
> > > ---------------------------------------------------------------------
> > > >> > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > >> > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > >> > >
> > > >> > >
> > > >> >
> > > >> > --
> > > >> >
> > > >> > Matthew de Detrich
> > > >> >
> > > >> > *Aiven Deutschland GmbH*
> > > >> >
> > > >> > Immanuelkirchstraße 26, 10405 Berlin
> > > >> >
> > > >> > Alexanderufer 3-7, 10117 Berlin
> > > >> >
> > > >> > Amtsgericht Charlottenburg, HRB 209739 B
> > > >> >
> > > >> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > > >> >
> > > >> > *m:* +491603708037
> > > >> >
> > > >> > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > >> For additional commands, e-mail: dev-help@pekko.apache.org
> > > >>
> > > >>
> > > >
> > > > --
> > > >
> > > > Matthew de Detrich
> > > >
> > > > *Aiven Deutschland GmbH*
> > > >
> > > > Immanuelkirchstraße 26, 10405 Berlin
> > > >
> > > > Alexanderufer 3-7, 10117 Berlin
> > > >
> > > > Amtsgericht Charlottenburg, HRB 209739 B
> > > >
> > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > > >
> > > > *m:* +491603708037
> > > >
> > > > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> > > >
> > >
> > >
> > > --
> > >
> > > Matthew de Detrich
> > >
> > > *Aiven Deutschland GmbH*
> > >
> > > Immanuelkirchstraße 26, 10405 Berlin
> > >
> > > Alexanderufer 3-7, 10117 Berlin
> > >
> > > Amtsgericht Charlottenburg, HRB 209739 B
> > >
> > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > >
> > > *m:* +491603708037
> > >
> > > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> > >
> >
>
>
> --
>
> Matthew de Detrich
>
> *Aiven Deutschland GmbH*
>
> Immanuelkirchstraße 26, 10405 Berlin
>
> Alexanderufer 3-7, 10117 Berlin
>
> Amtsgericht Charlottenburg, HRB 209739 B
>
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
>
> *m:* +491603708037
>
> *w:* aiven.io *e:* matthew.dedetrich@aiven.io
>
Re: having non-LTS releases
Posted by Matthew de Detrich <ma...@aiven.io.INVALID>.
So I have some good news for one of the big ticket items listed earlier,
Pekko is now using the latest version of sbt-osgi which contains a lot of
fixes and
improvements, see https://github.com/apache/incubator-pekko/pull/920. This
avoids
us having to drop sbt-osgi support (doing so is not off the table
completely but should
be made as a community decision later). Also
https://github.com/apache/incubator-pekko/pull/252
landed which is important since it's a behavioural change.
I would say the only other big item that should be handled before an M1
vote is
finishing off the inliner changes,
https://github.com/apache/incubator-pekko/pull/587
and the migration of akka to pekko clusters. A milestone release of these
changes
will provide ample opportunity for extensive testing to make sure as much
as possible
that the full release is without issues. I left out multi-release-jar
support, my feeling is
that this is too big of a change for M1 but It might make sense as an M2
or as part of 1.2.x.
If there is anything that's left out please mention it.
On Sun, Dec 24, 2023 at 7:42 AM kerr <he...@gmail.com> wrote:
> +1 for this, IIRC Matthew suggested this kind of release too.
> 何品
>
>
> Matthew de Detrich <ma...@aiven.io.invalid> 于2023年12月13日周三
> 07:06写道：
>
> > Apologies for necroing this topic, but there is one other feature I would
> > like to add to the M1
> > milestone release which is
> > https://github.com/apache/incubator-pekko/pull/252. The reason I
> > am pointing out this issue specifically is that it is a breaking
> behaviour
> > change (all of the
> > details are in the PR) so it needs to land for the 1.1.x series, ideally
> > for M1 so we can figure
> > out if there are any behavioural regressions.
> >
> > On Mon, Nov 6, 2023 at 8:40 PM Matthew de Detrich <
> > matthew.dedetrich@aiven.io> wrote:
> >
> > > > Some of those changes will likely also need backporting for
> > > 1.0.x releases.
> > >
> > > Indeed, the rolling migration from Akka to Pekko clusters is actually a
> > > feature for 1.0.x, but because
> > > of how its designed (i.e. there is a configuration for the
> > sender/receiver
> > > address), this feature and
> > > configuration also needs to exist for Pekko 1.1.0 otherwise the user
> > > experience will be extremely
> > > unintuitive.
> > >
> > > > I don't think a 1.1.0-M0 is warranted. This git tag has code that is
> > > very similar to Pekko 1.0.1. I don't see the merit in having multiple
> > > ASF contributors having to review such a release.
> > >
> > > It trivializes MiMa management which is worth the annoyance of doing a
> > > release. There really
> > > isn't any other way without breaking ASF policy, we basically have to
> > make
> > > a release that is
> > > not a "real" release.
> > >
> > > One thing to note is this doesn't occur that frequently (i.e. M0
> > > milestones), i.e. its only on a
> > > minor version bump and it can be argued that this release can be part
> of
> > > the formality of
> > > when we decide to make a 1.1.x branch, i.e. the community makes a
> > > decision/vote that
> > > at a certain point in time we are going to bump the minor version which
> > > requires a vote
> > > and that some vote is also used for the M0 release.
> > >
> > > In fact, now that I think/write about it, we really should have a
> formal
> > > vote when we make a
> > > minor version bump because it is a significant change, it shouldn't be
> > > done at whim (even
> > > if its from a PMC)
> > >
> > > > When I say LTS, I mean what versions will get patches for a long
> time.
> > > Java releases are a good example. If an org really needs a Java 22
> > > feature they can use Java 22 in production - but they are expected to
> > > upgrade to Java 23, etc. when those versions are released until a new
> > > Java LTS is released. There are other OSS equivalents. I am not
> > > talking about Commercial Support contracts - commercial entities are
> > > very welcome to fill this gap - this does not need to relate directly
> > > to the FOSS releases from the ASF project team.
> > >
> > > I understand the difference between LTS and commercial contract, it's
> > just
> > > that
> > > even the variables for how long the support is, is something that I
> don't
> > > think
> > > we have any ability to estimate concretely now. In summary, in my view
> > > it's too
> > > soon to even be discussing this.
> > >
> > > > If the consensus is to delay Pekko 1.1 until every candidate change
> is
> > > made - then fine - but this stops users from using features that are
> > > ready to try, like the Netty 4 support.
> > >
> > > As discussed on the github issue[1], this is a non issue. A milestone
> > > release
> > > will cater to anyone who really needs netty4 and as stated, it's just
> as
> > > tested
> > > as any other Pekko release is. If people are really desperate for
> netty4,
> > > then
> > > they can use the milestone (I would also note that I haven't seen any
> > > indication that anyone is begging for netty4 right now).
> > >
> > > > Since Pekko 1.1.0 full release seems like a long way away, it might
> be
> > > worth considering mechanisms to release the most useful changes
> > > earlier - in a way that Pekko 1.0 users can uptake.
> > >
> > > This is what milestones are for, i.e. they are precisely the mechanism
> > > to solve this issue. It also solves a host of other issues as discussed
> > > here[2].
> > >
> > > [1] https://github.com/apache/incubator-pekko/pull/778
> > > [2] https://lists.apache.org/thread/o494q89hhg64r5nwv4rnq6fsx9zofmny
> > >
> > > On Sun, Nov 5, 2023 at 10:57 PM PJ Fanning <fa...@gmail.com>
> wrote:
> > >
> > >> I have no objections to the general list of changes that we need for
> > >> 1.1.0. Some of those changes will likely also need backporting for
> > >> 1.0.x releases.
> > >>
> > >> A 1.1.0-M1 release makes sense. I want to delay it by a week or 2
> > >> while we decide what to do about the config logging (recent Akka CVE).
> > >>
> > >> I don't think a 1.1.0-M0 is warranted. This git tag has code that is
> > >> very similar to Pekko 1.0.1. I don't see the merit in having multiple
> > >> ASF contributors having to review such a release.
> > >>
> > >> I guess it is a separate conversation but there is a fair degree of
> > >> resistance to us dropping support for anything. I think we will need
> > >> to only drop support if it really makes things much easier for us.
> > >> Multi Release Jars seems like a better option than dropping Java 8
> > >> support (for instance).
> > >>
> > >> When I say LTS, I mean what versions will get patches for a long time.
> > >> Java releases are a good example. If an org really needs a Java 22
> > >> feature they can use Java 22 in production - but they are expected to
> > >> upgrade to Java 23, etc. when those versions are released until a new
> > >> Java LTS is released. There are other OSS equivalents. I am not
> > >> talking about Commercial Support contracts - commercial entities are
> > >> very welcome to fill this gap - this does not need to relate directly
> > >> to the FOSS releases from the ASF project team.
> > >>
> > >> If the consensus is to delay Pekko 1.1 until every candidate change is
> > >> made - then fine - but this stops users from using features that are
> > >> ready to try, like the Netty 4 support.
> > >>
> > >> Since Pekko 1.1.0 full release seems like a long way away, it might be
> > >> worth considering mechanisms to release the most useful changes
> > >> earlier - in a way that Pekko 1.0 users can uptake.
> > >>
> > >>
> > >> On Sun, 5 Nov 2023 at 12:59, Matthew de Detrich
> > >> <ma...@aiven.io.invalid> wrote:
> > >> >
> > >> > So my take on this
> > >> >
> > >> > - We should do milestones to solve the general problem you are
> > alluding
> > >> to,
> > >> > i.e. the M1 milestone that you suggest that we vote on (we should
> also
> > >> do
> > >> > the M0 milestone which is at the exact moment when a new bump to
> minor
> > >> > version is done, reasoning why is given in this thread[1]). I would
> > >> argue
> > >> > that doing an M1 now is a good idea and then an M2 once other
> critical
> > >> > features land (such as inliner which is mentioned in the below
> point)
> > >> > - There are some critical features that need to be merged before a
> > >> release
> > >> > of 1.1.0 Pekko Core is ever made (and 1.1.0 Pekko core needs to be
> > >> released
> > >> > before any other 1.1.0 releases for the other modules) due to
> > technical
> > >> > reasons. On the top of my head the critical features so far are the
> > >> > inliner[2] and rolling update migration of Akka to Pekko
> clusters[3].
> > I
> > >> > think it's achievable to get [2] and [3] done in a few months time,
> > but
> > >> we
> > >> > would have to focus on getting it over the line ([2] is already
> > "done",
> > >> it
> > >> > just needs a review and testing in downstream modules, [3] likely
> > needs
> > >> > more work and most of all testing so that it works as expected).
> > >> > - Regarding LTS, I don't think we should entertain the idea now. We
> > >> have no
> > >> > idea of what and how an LTS can work and we don't even have the
> > capacity
> > >> > for it. It might even be a thing that LTS's are "someone else's"
> > problem
> > >> > (Pekko is open source after all). I think the most critical thing is
> > >> > sticking to semantic versioning, such an expectation is manageable
> for
> > >> us
> > >> > and I would argue is kind of a requirement for large open source
> > >> projects
> > >> > like Pekko
> > >> > - Fixing the manager name [4] should also be fixed for 1.1.0
> (actually
> > >> if
> > >> > anything this should be fixed for 1.0.x branch as well)
> > >> > - As kind of a stretch goal, sbt-multi-release-jar support for
> > 1.1.0[5]
> > >> > would be awesome as it would unblock a **lot** of things while also
> > >> keeping
> > >> > part of the community happy
> > >> > - Releasing pekko 1.1.0 with the latest sbt-osgi (which apparently
> > >> fixes a
> > >> > lot of pain points versus the current osgi used in Pekko 1.0.x)
> would
> > be
> > >> > another nice stretch goal, currently there is one issue with
> duplicate
> > >> > classes but we now have infrastructure set up[6] so that we can
> > properly
> > >> > test such changes.
> > >> >
> > >> > Note that a lot of the underlying reasoning behind my points are
> also
> > >> > strategic, i.e. keeping features which can be considered critical to
> > >> Pekko
> > >> > and/or current Akka users which don't require to much effort
> > (basically
> > >> > anything that gives a reason for people to use/migrate to Pekko
> while
> > >> not
> > >> > breaking the i.e. our bank so to speak). I know that there has been
> a
> > >> push
> > >> > to do things like drop JDK 8, Scala 2.12, osgi etc etc due to death
> > by a
> > >> > thousand cuts but tbh objectively speaking these issues are not
> taking
> > >> up
> > >> > that much time (at least personally by far the largest amount of
> time
> > >> spent
> > >> > is just overhead of having to do so many releases and validate them,
> > >> really
> > >> > looking forward to the day when we can automate everything with
> > >> > sbt-reproducible-builds/jardiff/create jars in ci etc etc). Pekko
> > 2.0.x
> > >> > series is when we can look forward to drop a lot of this "annoying
> > >> > maintenance" stuff and I would actually strongly argue that at the
> > time
> > >> > when we start looking at Pekko 2.0.x we actually get a better idea
> of
> > >> what
> > >> > our Pekko users look like, because as has been shown due to the
> chaos
> > >> > created from the license change very few us had any somewhat
> realistic
> > >> lens
> > >> > as to how the Pekko community (specifically users) look like, i.e.
> > while
> > >> > the OS would **LOVE** to get rid of JDK 1.8 support it just so
> happens
> > >> that
> > >> > a lot of people still need to use JDK 1.8 and even though there are
> > >> reasons
> > >> > to move away from 1.8 evidently they aren't relevant.
> > >> >
> > >> > [1]
> https://lists.apache.org/thread/o494q89hhg64r5nwv4rnq6fsx9zofmny
> > >> > [2] https://github.com/apache/incubator-pekko/pull/305
> > >> > [3] https://github.com/apache/incubator-pekko/pull/765
> > >> > [4] https://github.com/apache/incubator-pekko/pull/587
> > >> > [5] https://github.com/sbt/sbt-multi-release-jar/issues/22
> > >> > [6] https://github.com/apache/incubator-pekko/issues/75
> > >> >
> > >> > On Sun, Nov 5, 2023 at 12:12 PM PJ Fanning <fa...@apache.org>
> > >> wrote:
> > >> >
> > >> > > The core pekko repo [1] has quite a few changes in its main branch
> > >> that
> > >> > > are are targeted at a future 1.1.0 release.
> > >> > >
> > >> > > We haven't really agreed on what to do with the code that was
> > already
> > >> > > deprecated in the Akka era and there is also the issue of the
> > >> ApiMayChange
> > >> > > annotations on some of the APIs.
> > >> > >
> > >> > > There are also some new features that developers want to add.
> > >> > >
> > >> > > We don't have a great deal of developer effort available to us.
> > >> > >
> > >> > > I suspect that we need to need to balance the need to release some
> > of
> > >> the
> > >> > > 1.1 changes and then maybe try to make another batch of changes in
> > >> Pekko
> > >> > > 1.2.
> > >> > >
> > >> > > What if we aimed to do a Pekko 1.1.0 release in a few months and
> > said
> > >> that
> > >> > > it was not a Long Term Support release? If we go down this line,
> we
> > >> would
> > >> > > probably want to have a tentative plan as to when a new LTS
> release
> > >> would
> > >> > > happen.
> > >> > >
> > >> > > An example of something that would be useful to release would be
> the
> > >> > > netty4 support. I know that the Apache Flink team would like to
> use
> > >> this.
> > >> > >
> > >> > > Alternatively, we could do a Pekko 1.1.0-M1 release. I suspect
> that
> > we
> > >> > > would end up with a fair number of these and the M version number
> > >> would
> > >> > > discourage uptake (except for testing).
> > >> > >
> > >> > > What are people's thoughts on the options?
> > >> > >
> > >> > >
> > >> > >
> > >> > > [1] https://github.com/apache/incubator-pekko
> > >> > >
> > >> > >
> > ---------------------------------------------------------------------
> > >> > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > >> > > For additional commands, e-mail: dev-help@pekko.apache.org
> > >> > >
> > >> > >
> > >> >
> > >> > --
> > >> >
> > >> > Matthew de Detrich
> > >> >
> > >> > *Aiven Deutschland GmbH*
> > >> >
> > >> > Immanuelkirchstraße 26, 10405 Berlin
> > >> >
> > >> > Alexanderufer 3-7, 10117 Berlin
> > >> >
> > >> > Amtsgericht Charlottenburg, HRB 209739 B
> > >> >
> > >> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > >> >
> > >> > *m:* +491603708037
> > >> >
> > >> > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > >> For additional commands, e-mail: dev-help@pekko.apache.org
> > >>
> > >>
> > >
> > > --
> > >
> > > Matthew de Detrich
> > >
> > > *Aiven Deutschland GmbH*
> > >
> > > Immanuelkirchstraße 26, 10405 Berlin
> > >
> > > Alexanderufer 3-7, 10117 Berlin
> > >
> > > Amtsgericht Charlottenburg, HRB 209739 B
> > >
> > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > >
> > > *m:* +491603708037
> > >
> > > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> > >
> >
> >
> > --
> >
> > Matthew de Detrich
> >
> > *Aiven Deutschland GmbH*
> >
> > Immanuelkirchstraße 26, 10405 Berlin
> >
> > Alexanderufer 3-7, 10117 Berlin
> >
> > Amtsgericht Charlottenburg, HRB 209739 B
> >
> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> >
> > *m:* +491603708037
> >
> > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> >
>
--
Matthew de Detrich
*Aiven Deutschland GmbH*
Immanuelkirchstraße 26, 10405 Berlin
Alexanderufer 3-7, 10117 Berlin
Amtsgericht Charlottenburg, HRB 209739 B
Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
*m:* +491603708037
*w:* aiven.io *e:* matthew.dedetrich@aiven.io
Re: having non-LTS releases
Posted by kerr <he...@gmail.com>.
+1 for this, IIRC Matthew suggested this kind of release too.
何品
Matthew de Detrich <ma...@aiven.io.invalid> 于2023年12月13日周三
07:06写道：
> Apologies for necroing this topic, but there is one other feature I would
> like to add to the M1
> milestone release which is
> https://github.com/apache/incubator-pekko/pull/252. The reason I
> am pointing out this issue specifically is that it is a breaking behaviour
> change (all of the
> details are in the PR) so it needs to land for the 1.1.x series, ideally
> for M1 so we can figure
> out if there are any behavioural regressions.
>
> On Mon, Nov 6, 2023 at 8:40 PM Matthew de Detrich <
> matthew.dedetrich@aiven.io> wrote:
>
> > > Some of those changes will likely also need backporting for
> > 1.0.x releases.
> >
> > Indeed, the rolling migration from Akka to Pekko clusters is actually a
> > feature for 1.0.x, but because
> > of how its designed (i.e. there is a configuration for the
> sender/receiver
> > address), this feature and
> > configuration also needs to exist for Pekko 1.1.0 otherwise the user
> > experience will be extremely
> > unintuitive.
> >
> > > I don't think a 1.1.0-M0 is warranted. This git tag has code that is
> > very similar to Pekko 1.0.1. I don't see the merit in having multiple
> > ASF contributors having to review such a release.
> >
> > It trivializes MiMa management which is worth the annoyance of doing a
> > release. There really
> > isn't any other way without breaking ASF policy, we basically have to
> make
> > a release that is
> > not a "real" release.
> >
> > One thing to note is this doesn't occur that frequently (i.e. M0
> > milestones), i.e. its only on a
> > minor version bump and it can be argued that this release can be part of
> > the formality of
> > when we decide to make a 1.1.x branch, i.e. the community makes a
> > decision/vote that
> > at a certain point in time we are going to bump the minor version which
> > requires a vote
> > and that some vote is also used for the M0 release.
> >
> > In fact, now that I think/write about it, we really should have a formal
> > vote when we make a
> > minor version bump because it is a significant change, it shouldn't be
> > done at whim (even
> > if its from a PMC)
> >
> > > When I say LTS, I mean what versions will get patches for a long time.
> > Java releases are a good example. If an org really needs a Java 22
> > feature they can use Java 22 in production - but they are expected to
> > upgrade to Java 23, etc. when those versions are released until a new
> > Java LTS is released. There are other OSS equivalents. I am not
> > talking about Commercial Support contracts - commercial entities are
> > very welcome to fill this gap - this does not need to relate directly
> > to the FOSS releases from the ASF project team.
> >
> > I understand the difference between LTS and commercial contract, it's
> just
> > that
> > even the variables for how long the support is, is something that I don't
> > think
> > we have any ability to estimate concretely now. In summary, in my view
> > it's too
> > soon to even be discussing this.
> >
> > > If the consensus is to delay Pekko 1.1 until every candidate change is
> > made - then fine - but this stops users from using features that are
> > ready to try, like the Netty 4 support.
> >
> > As discussed on the github issue[1], this is a non issue. A milestone
> > release
> > will cater to anyone who really needs netty4 and as stated, it's just as
> > tested
> > as any other Pekko release is. If people are really desperate for netty4,
> > then
> > they can use the milestone (I would also note that I haven't seen any
> > indication that anyone is begging for netty4 right now).
> >
> > > Since Pekko 1.1.0 full release seems like a long way away, it might be
> > worth considering mechanisms to release the most useful changes
> > earlier - in a way that Pekko 1.0 users can uptake.
> >
> > This is what milestones are for, i.e. they are precisely the mechanism
> > to solve this issue. It also solves a host of other issues as discussed
> > here[2].
> >
> > [1] https://github.com/apache/incubator-pekko/pull/778
> > [2] https://lists.apache.org/thread/o494q89hhg64r5nwv4rnq6fsx9zofmny
> >
> > On Sun, Nov 5, 2023 at 10:57 PM PJ Fanning <fa...@gmail.com> wrote:
> >
> >> I have no objections to the general list of changes that we need for
> >> 1.1.0. Some of those changes will likely also need backporting for
> >> 1.0.x releases.
> >>
> >> A 1.1.0-M1 release makes sense. I want to delay it by a week or 2
> >> while we decide what to do about the config logging (recent Akka CVE).
> >>
> >> I don't think a 1.1.0-M0 is warranted. This git tag has code that is
> >> very similar to Pekko 1.0.1. I don't see the merit in having multiple
> >> ASF contributors having to review such a release.
> >>
> >> I guess it is a separate conversation but there is a fair degree of
> >> resistance to us dropping support for anything. I think we will need
> >> to only drop support if it really makes things much easier for us.
> >> Multi Release Jars seems like a better option than dropping Java 8
> >> support (for instance).
> >>
> >> When I say LTS, I mean what versions will get patches for a long time.
> >> Java releases are a good example. If an org really needs a Java 22
> >> feature they can use Java 22 in production - but they are expected to
> >> upgrade to Java 23, etc. when those versions are released until a new
> >> Java LTS is released. There are other OSS equivalents. I am not
> >> talking about Commercial Support contracts - commercial entities are
> >> very welcome to fill this gap - this does not need to relate directly
> >> to the FOSS releases from the ASF project team.
> >>
> >> If the consensus is to delay Pekko 1.1 until every candidate change is
> >> made - then fine - but this stops users from using features that are
> >> ready to try, like the Netty 4 support.
> >>
> >> Since Pekko 1.1.0 full release seems like a long way away, it might be
> >> worth considering mechanisms to release the most useful changes
> >> earlier - in a way that Pekko 1.0 users can uptake.
> >>
> >>
> >> On Sun, 5 Nov 2023 at 12:59, Matthew de Detrich
> >> <ma...@aiven.io.invalid> wrote:
> >> >
> >> > So my take on this
> >> >
> >> > - We should do milestones to solve the general problem you are
> alluding
> >> to,
> >> > i.e. the M1 milestone that you suggest that we vote on (we should also
> >> do
> >> > the M0 milestone which is at the exact moment when a new bump to minor
> >> > version is done, reasoning why is given in this thread[1]). I would
> >> argue
> >> > that doing an M1 now is a good idea and then an M2 once other critical
> >> > features land (such as inliner which is mentioned in the below point)
> >> > - There are some critical features that need to be merged before a
> >> release
> >> > of 1.1.0 Pekko Core is ever made (and 1.1.0 Pekko core needs to be
> >> released
> >> > before any other 1.1.0 releases for the other modules) due to
> technical
> >> > reasons. On the top of my head the critical features so far are the
> >> > inliner[2] and rolling update migration of Akka to Pekko clusters[3].
> I
> >> > think it's achievable to get [2] and [3] done in a few months time,
> but
> >> we
> >> > would have to focus on getting it over the line ([2] is already
> "done",
> >> it
> >> > just needs a review and testing in downstream modules, [3] likely
> needs
> >> > more work and most of all testing so that it works as expected).
> >> > - Regarding LTS, I don't think we should entertain the idea now. We
> >> have no
> >> > idea of what and how an LTS can work and we don't even have the
> capacity
> >> > for it. It might even be a thing that LTS's are "someone else's"
> problem
> >> > (Pekko is open source after all). I think the most critical thing is
> >> > sticking to semantic versioning, such an expectation is manageable for
> >> us
> >> > and I would argue is kind of a requirement for large open source
> >> projects
> >> > like Pekko
> >> > - Fixing the manager name [4] should also be fixed for 1.1.0 (actually
> >> if
> >> > anything this should be fixed for 1.0.x branch as well)
> >> > - As kind of a stretch goal, sbt-multi-release-jar support for
> 1.1.0[5]
> >> > would be awesome as it would unblock a **lot** of things while also
> >> keeping
> >> > part of the community happy
> >> > - Releasing pekko 1.1.0 with the latest sbt-osgi (which apparently
> >> fixes a
> >> > lot of pain points versus the current osgi used in Pekko 1.0.x) would
> be
> >> > another nice stretch goal, currently there is one issue with duplicate
> >> > classes but we now have infrastructure set up[6] so that we can
> properly
> >> > test such changes.
> >> >
> >> > Note that a lot of the underlying reasoning behind my points are also
> >> > strategic, i.e. keeping features which can be considered critical to
> >> Pekko
> >> > and/or current Akka users which don't require to much effort
> (basically
> >> > anything that gives a reason for people to use/migrate to Pekko while
> >> not
> >> > breaking the i.e. our bank so to speak). I know that there has been a
> >> push
> >> > to do things like drop JDK 8, Scala 2.12, osgi etc etc due to death
> by a
> >> > thousand cuts but tbh objectively speaking these issues are not taking
> >> up
> >> > that much time (at least personally by far the largest amount of time
> >> spent
> >> > is just overhead of having to do so many releases and validate them,
> >> really
> >> > looking forward to the day when we can automate everything with
> >> > sbt-reproducible-builds/jardiff/create jars in ci etc etc). Pekko
> 2.0.x
> >> > series is when we can look forward to drop a lot of this "annoying
> >> > maintenance" stuff and I would actually strongly argue that at the
> time
> >> > when we start looking at Pekko 2.0.x we actually get a better idea of
> >> what
> >> > our Pekko users look like, because as has been shown due to the chaos
> >> > created from the license change very few us had any somewhat realistic
> >> lens
> >> > as to how the Pekko community (specifically users) look like, i.e.
> while
> >> > the OS would **LOVE** to get rid of JDK 1.8 support it just so happens
> >> that
> >> > a lot of people still need to use JDK 1.8 and even though there are
> >> reasons
> >> > to move away from 1.8 evidently they aren't relevant.
> >> >
> >> > [1] https://lists.apache.org/thread/o494q89hhg64r5nwv4rnq6fsx9zofmny
> >> > [2] https://github.com/apache/incubator-pekko/pull/305
> >> > [3] https://github.com/apache/incubator-pekko/pull/765
> >> > [4] https://github.com/apache/incubator-pekko/pull/587
> >> > [5] https://github.com/sbt/sbt-multi-release-jar/issues/22
> >> > [6] https://github.com/apache/incubator-pekko/issues/75
> >> >
> >> > On Sun, Nov 5, 2023 at 12:12 PM PJ Fanning <fa...@apache.org>
> >> wrote:
> >> >
> >> > > The core pekko repo [1] has quite a few changes in its main branch
> >> that
> >> > > are are targeted at a future 1.1.0 release.
> >> > >
> >> > > We haven't really agreed on what to do with the code that was
> already
> >> > > deprecated in the Akka era and there is also the issue of the
> >> ApiMayChange
> >> > > annotations on some of the APIs.
> >> > >
> >> > > There are also some new features that developers want to add.
> >> > >
> >> > > We don't have a great deal of developer effort available to us.
> >> > >
> >> > > I suspect that we need to need to balance the need to release some
> of
> >> the
> >> > > 1.1 changes and then maybe try to make another batch of changes in
> >> Pekko
> >> > > 1.2.
> >> > >
> >> > > What if we aimed to do a Pekko 1.1.0 release in a few months and
> said
> >> that
> >> > > it was not a Long Term Support release? If we go down this line, we
> >> would
> >> > > probably want to have a tentative plan as to when a new LTS release
> >> would
> >> > > happen.
> >> > >
> >> > > An example of something that would be useful to release would be the
> >> > > netty4 support. I know that the Apache Flink team would like to use
> >> this.
> >> > >
> >> > > Alternatively, we could do a Pekko 1.1.0-M1 release. I suspect that
> we
> >> > > would end up with a fair number of these and the M version number
> >> would
> >> > > discourage uptake (except for testing).
> >> > >
> >> > > What are people's thoughts on the options?
> >> > >
> >> > >
> >> > >
> >> > > [1] https://github.com/apache/incubator-pekko
> >> > >
> >> > >
> ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> >> > > For additional commands, e-mail: dev-help@pekko.apache.org
> >> > >
> >> > >
> >> >
> >> > --
> >> >
> >> > Matthew de Detrich
> >> >
> >> > *Aiven Deutschland GmbH*
> >> >
> >> > Immanuelkirchstraße 26, 10405 Berlin
> >> >
> >> > Alexanderufer 3-7, 10117 Berlin
> >> >
> >> > Amtsgericht Charlottenburg, HRB 209739 B
> >> >
> >> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> >> >
> >> > *m:* +491603708037
> >> >
> >> > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> >> For additional commands, e-mail: dev-help@pekko.apache.org
> >>
> >>
> >
> > --
> >
> > Matthew de Detrich
> >
> > *Aiven Deutschland GmbH*
> >
> > Immanuelkirchstraße 26, 10405 Berlin
> >
> > Alexanderufer 3-7, 10117 Berlin
> >
> > Amtsgericht Charlottenburg, HRB 209739 B
> >
> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> >
> > *m:* +491603708037
> >
> > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> >
>
>
> --
>
> Matthew de Detrich
>
> *Aiven Deutschland GmbH*
>
> Immanuelkirchstraße 26, 10405 Berlin
>
> Alexanderufer 3-7, 10117 Berlin
>
> Amtsgericht Charlottenburg, HRB 209739 B
>
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
>
> *m:* +491603708037
>
> *w:* aiven.io *e:* matthew.dedetrich@aiven.io
>
Re: having non-LTS releases
Posted by Matthew de Detrich <ma...@aiven.io.INVALID>.
Apologies for necroing this topic, but there is one other feature I would
like to add to the M1
milestone release which is
https://github.com/apache/incubator-pekko/pull/252. The reason I
am pointing out this issue specifically is that it is a breaking behaviour
change (all of the
details are in the PR) so it needs to land for the 1.1.x series, ideally
for M1 so we can figure
out if there are any behavioural regressions.
On Mon, Nov 6, 2023 at 8:40 PM Matthew de Detrich <
matthew.dedetrich@aiven.io> wrote:
> > Some of those changes will likely also need backporting for
> 1.0.x releases.
>
> Indeed, the rolling migration from Akka to Pekko clusters is actually a
> feature for 1.0.x, but because
> of how its designed (i.e. there is a configuration for the sender/receiver
> address), this feature and
> configuration also needs to exist for Pekko 1.1.0 otherwise the user
> experience will be extremely
> unintuitive.
>
> > I don't think a 1.1.0-M0 is warranted. This git tag has code that is
> very similar to Pekko 1.0.1. I don't see the merit in having multiple
> ASF contributors having to review such a release.
>
> It trivializes MiMa management which is worth the annoyance of doing a
> release. There really
> isn't any other way without breaking ASF policy, we basically have to make
> a release that is
> not a "real" release.
>
> One thing to note is this doesn't occur that frequently (i.e. M0
> milestones), i.e. its only on a
> minor version bump and it can be argued that this release can be part of
> the formality of
> when we decide to make a 1.1.x branch, i.e. the community makes a
> decision/vote that
> at a certain point in time we are going to bump the minor version which
> requires a vote
> and that some vote is also used for the M0 release.
>
> In fact, now that I think/write about it, we really should have a formal
> vote when we make a
> minor version bump because it is a significant change, it shouldn't be
> done at whim (even
> if its from a PMC)
>
> > When I say LTS, I mean what versions will get patches for a long time.
> Java releases are a good example. If an org really needs a Java 22
> feature they can use Java 22 in production - but they are expected to
> upgrade to Java 23, etc. when those versions are released until a new
> Java LTS is released. There are other OSS equivalents. I am not
> talking about Commercial Support contracts - commercial entities are
> very welcome to fill this gap - this does not need to relate directly
> to the FOSS releases from the ASF project team.
>
> I understand the difference between LTS and commercial contract, it's just
> that
> even the variables for how long the support is, is something that I don't
> think
> we have any ability to estimate concretely now. In summary, in my view
> it's too
> soon to even be discussing this.
>
> > If the consensus is to delay Pekko 1.1 until every candidate change is
> made - then fine - but this stops users from using features that are
> ready to try, like the Netty 4 support.
>
> As discussed on the github issue[1], this is a non issue. A milestone
> release
> will cater to anyone who really needs netty4 and as stated, it's just as
> tested
> as any other Pekko release is. If people are really desperate for netty4,
> then
> they can use the milestone (I would also note that I haven't seen any
> indication that anyone is begging for netty4 right now).
>
> > Since Pekko 1.1.0 full release seems like a long way away, it might be
> worth considering mechanisms to release the most useful changes
> earlier - in a way that Pekko 1.0 users can uptake.
>
> This is what milestones are for, i.e. they are precisely the mechanism
> to solve this issue. It also solves a host of other issues as discussed
> here[2].
>
> [1] https://github.com/apache/incubator-pekko/pull/778
> [2] https://lists.apache.org/thread/o494q89hhg64r5nwv4rnq6fsx9zofmny
>
> On Sun, Nov 5, 2023 at 10:57 PM PJ Fanning <fa...@gmail.com> wrote:
>
>> I have no objections to the general list of changes that we need for
>> 1.1.0. Some of those changes will likely also need backporting for
>> 1.0.x releases.
>>
>> A 1.1.0-M1 release makes sense. I want to delay it by a week or 2
>> while we decide what to do about the config logging (recent Akka CVE).
>>
>> I don't think a 1.1.0-M0 is warranted. This git tag has code that is
>> very similar to Pekko 1.0.1. I don't see the merit in having multiple
>> ASF contributors having to review such a release.
>>
>> I guess it is a separate conversation but there is a fair degree of
>> resistance to us dropping support for anything. I think we will need
>> to only drop support if it really makes things much easier for us.
>> Multi Release Jars seems like a better option than dropping Java 8
>> support (for instance).
>>
>> When I say LTS, I mean what versions will get patches for a long time.
>> Java releases are a good example. If an org really needs a Java 22
>> feature they can use Java 22 in production - but they are expected to
>> upgrade to Java 23, etc. when those versions are released until a new
>> Java LTS is released. There are other OSS equivalents. I am not
>> talking about Commercial Support contracts - commercial entities are
>> very welcome to fill this gap - this does not need to relate directly
>> to the FOSS releases from the ASF project team.
>>
>> If the consensus is to delay Pekko 1.1 until every candidate change is
>> made - then fine - but this stops users from using features that are
>> ready to try, like the Netty 4 support.
>>
>> Since Pekko 1.1.0 full release seems like a long way away, it might be
>> worth considering mechanisms to release the most useful changes
>> earlier - in a way that Pekko 1.0 users can uptake.
>>
>>
>> On Sun, 5 Nov 2023 at 12:59, Matthew de Detrich
>> <ma...@aiven.io.invalid> wrote:
>> >
>> > So my take on this
>> >
>> > - We should do milestones to solve the general problem you are alluding
>> to,
>> > i.e. the M1 milestone that you suggest that we vote on (we should also
>> do
>> > the M0 milestone which is at the exact moment when a new bump to minor
>> > version is done, reasoning why is given in this thread[1]). I would
>> argue
>> > that doing an M1 now is a good idea and then an M2 once other critical
>> > features land (such as inliner which is mentioned in the below point)
>> > - There are some critical features that need to be merged before a
>> release
>> > of 1.1.0 Pekko Core is ever made (and 1.1.0 Pekko core needs to be
>> released
>> > before any other 1.1.0 releases for the other modules) due to technical
>> > reasons. On the top of my head the critical features so far are the
>> > inliner[2] and rolling update migration of Akka to Pekko clusters[3]. I
>> > think it's achievable to get [2] and [3] done in a few months time, but
>> we
>> > would have to focus on getting it over the line ([2] is already "done",
>> it
>> > just needs a review and testing in downstream modules, [3] likely needs
>> > more work and most of all testing so that it works as expected).
>> > - Regarding LTS, I don't think we should entertain the idea now. We
>> have no
>> > idea of what and how an LTS can work and we don't even have the capacity
>> > for it. It might even be a thing that LTS's are "someone else's" problem
>> > (Pekko is open source after all). I think the most critical thing is
>> > sticking to semantic versioning, such an expectation is manageable for
>> us
>> > and I would argue is kind of a requirement for large open source
>> projects
>> > like Pekko
>> > - Fixing the manager name [4] should also be fixed for 1.1.0 (actually
>> if
>> > anything this should be fixed for 1.0.x branch as well)
>> > - As kind of a stretch goal, sbt-multi-release-jar support for 1.1.0[5]
>> > would be awesome as it would unblock a **lot** of things while also
>> keeping
>> > part of the community happy
>> > - Releasing pekko 1.1.0 with the latest sbt-osgi (which apparently
>> fixes a
>> > lot of pain points versus the current osgi used in Pekko 1.0.x) would be
>> > another nice stretch goal, currently there is one issue with duplicate
>> > classes but we now have infrastructure set up[6] so that we can properly
>> > test such changes.
>> >
>> > Note that a lot of the underlying reasoning behind my points are also
>> > strategic, i.e. keeping features which can be considered critical to
>> Pekko
>> > and/or current Akka users which don't require to much effort (basically
>> > anything that gives a reason for people to use/migrate to Pekko while
>> not
>> > breaking the i.e. our bank so to speak). I know that there has been a
>> push
>> > to do things like drop JDK 8, Scala 2.12, osgi etc etc due to death by a
>> > thousand cuts but tbh objectively speaking these issues are not taking
>> up
>> > that much time (at least personally by far the largest amount of time
>> spent
>> > is just overhead of having to do so many releases and validate them,
>> really
>> > looking forward to the day when we can automate everything with
>> > sbt-reproducible-builds/jardiff/create jars in ci etc etc). Pekko 2.0.x
>> > series is when we can look forward to drop a lot of this "annoying
>> > maintenance" stuff and I would actually strongly argue that at the time
>> > when we start looking at Pekko 2.0.x we actually get a better idea of
>> what
>> > our Pekko users look like, because as has been shown due to the chaos
>> > created from the license change very few us had any somewhat realistic
>> lens
>> > as to how the Pekko community (specifically users) look like, i.e. while
>> > the OS would **LOVE** to get rid of JDK 1.8 support it just so happens
>> that
>> > a lot of people still need to use JDK 1.8 and even though there are
>> reasons
>> > to move away from 1.8 evidently they aren't relevant.
>> >
>> > [1] https://lists.apache.org/thread/o494q89hhg64r5nwv4rnq6fsx9zofmny
>> > [2] https://github.com/apache/incubator-pekko/pull/305
>> > [3] https://github.com/apache/incubator-pekko/pull/765
>> > [4] https://github.com/apache/incubator-pekko/pull/587
>> > [5] https://github.com/sbt/sbt-multi-release-jar/issues/22
>> > [6] https://github.com/apache/incubator-pekko/issues/75
>> >
>> > On Sun, Nov 5, 2023 at 12:12 PM PJ Fanning <fa...@apache.org>
>> wrote:
>> >
>> > > The core pekko repo [1] has quite a few changes in its main branch
>> that
>> > > are are targeted at a future 1.1.0 release.
>> > >
>> > > We haven't really agreed on what to do with the code that was already
>> > > deprecated in the Akka era and there is also the issue of the
>> ApiMayChange
>> > > annotations on some of the APIs.
>> > >
>> > > There are also some new features that developers want to add.
>> > >
>> > > We don't have a great deal of developer effort available to us.
>> > >
>> > > I suspect that we need to need to balance the need to release some of
>> the
>> > > 1.1 changes and then maybe try to make another batch of changes in
>> Pekko
>> > > 1.2.
>> > >
>> > > What if we aimed to do a Pekko 1.1.0 release in a few months and said
>> that
>> > > it was not a Long Term Support release? If we go down this line, we
>> would
>> > > probably want to have a tentative plan as to when a new LTS release
>> would
>> > > happen.
>> > >
>> > > An example of something that would be useful to release would be the
>> > > netty4 support. I know that the Apache Flink team would like to use
>> this.
>> > >
>> > > Alternatively, we could do a Pekko 1.1.0-M1 release. I suspect that we
>> > > would end up with a fair number of these and the M version number
>> would
>> > > discourage uptake (except for testing).
>> > >
>> > > What are people's thoughts on the options?
>> > >
>> > >
>> > >
>> > > [1] https://github.com/apache/incubator-pekko
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
>> > > For additional commands, e-mail: dev-help@pekko.apache.org
>> > >
>> > >
>> >
>> > --
>> >
>> > Matthew de Detrich
>> >
>> > *Aiven Deutschland GmbH*
>> >
>> > Immanuelkirchstraße 26, 10405 Berlin
>> >
>> > Alexanderufer 3-7, 10117 Berlin
>> >
>> > Amtsgericht Charlottenburg, HRB 209739 B
>> >
>> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
>> >
>> > *m:* +491603708037
>> >
>> > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
>> For additional commands, e-mail: dev-help@pekko.apache.org
>>
>>
>
> --
>
> Matthew de Detrich
>
> *Aiven Deutschland GmbH*
>
> Immanuelkirchstraße 26, 10405 Berlin
>
> Alexanderufer 3-7, 10117 Berlin
>
> Amtsgericht Charlottenburg, HRB 209739 B
>
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
>
> *m:* +491603708037
>
> *w:* aiven.io *e:* matthew.dedetrich@aiven.io
>
--
Matthew de Detrich
*Aiven Deutschland GmbH*
Immanuelkirchstraße 26, 10405 Berlin
Alexanderufer 3-7, 10117 Berlin
Amtsgericht Charlottenburg, HRB 209739 B
Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
*m:* +491603708037
*w:* aiven.io *e:* matthew.dedetrich@aiven.io
Re: having non-LTS releases
Posted by Matthew de Detrich <ma...@aiven.io.INVALID>.
> Some of those changes will likely also need backporting for
1.0.x releases.
Indeed, the rolling migration from Akka to Pekko clusters is actually a
feature for 1.0.x, but because
of how its designed (i.e. there is a configuration for the sender/receiver
address), this feature and
configuration also needs to exist for Pekko 1.1.0 otherwise the user
experience will be extremely
unintuitive.
> I don't think a 1.1.0-M0 is warranted. This git tag has code that is
very similar to Pekko 1.0.1. I don't see the merit in having multiple
ASF contributors having to review such a release.
It trivializes MiMa management which is worth the annoyance of doing a
release. There really
isn't any other way without breaking ASF policy, we basically have to make
a release that is
not a "real" release.
One thing to note is this doesn't occur that frequently (i.e. M0
milestones), i.e. its only on a
minor version bump and it can be argued that this release can be part of
the formality of
when we decide to make a 1.1.x branch, i.e. the community makes a
decision/vote that
at a certain point in time we are going to bump the minor version which
requires a vote
and that some vote is also used for the M0 release.
In fact, now that I think/write about it, we really should have a formal
vote when we make a
minor version bump because it is a significant change, it shouldn't be done
at whim (even
if its from a PMC)
> When I say LTS, I mean what versions will get patches for a long time.
Java releases are a good example. If an org really needs a Java 22
feature they can use Java 22 in production - but they are expected to
upgrade to Java 23, etc. when those versions are released until a new
Java LTS is released. There are other OSS equivalents. I am not
talking about Commercial Support contracts - commercial entities are
very welcome to fill this gap - this does not need to relate directly
to the FOSS releases from the ASF project team.
I understand the difference between LTS and commercial contract, it's just
that
even the variables for how long the support is, is something that I don't
think
we have any ability to estimate concretely now. In summary, in my view it's
too
soon to even be discussing this.
> If the consensus is to delay Pekko 1.1 until every candidate change is
made - then fine - but this stops users from using features that are
ready to try, like the Netty 4 support.
As discussed on the github issue[1], this is a non issue. A milestone
release
will cater to anyone who really needs netty4 and as stated, it's just as
tested
as any other Pekko release is. If people are really desperate for netty4,
then
they can use the milestone (I would also note that I haven't seen any
indication that anyone is begging for netty4 right now).
> Since Pekko 1.1.0 full release seems like a long way away, it might be
worth considering mechanisms to release the most useful changes
earlier - in a way that Pekko 1.0 users can uptake.
This is what milestones are for, i.e. they are precisely the mechanism
to solve this issue. It also solves a host of other issues as discussed
here[2].
[1] https://github.com/apache/incubator-pekko/pull/778
[2] https://lists.apache.org/thread/o494q89hhg64r5nwv4rnq6fsx9zofmny
On Sun, Nov 5, 2023 at 10:57 PM PJ Fanning <fa...@gmail.com> wrote:
> I have no objections to the general list of changes that we need for
> 1.1.0. Some of those changes will likely also need backporting for
> 1.0.x releases.
>
> A 1.1.0-M1 release makes sense. I want to delay it by a week or 2
> while we decide what to do about the config logging (recent Akka CVE).
>
> I don't think a 1.1.0-M0 is warranted. This git tag has code that is
> very similar to Pekko 1.0.1. I don't see the merit in having multiple
> ASF contributors having to review such a release.
>
> I guess it is a separate conversation but there is a fair degree of
> resistance to us dropping support for anything. I think we will need
> to only drop support if it really makes things much easier for us.
> Multi Release Jars seems like a better option than dropping Java 8
> support (for instance).
>
> When I say LTS, I mean what versions will get patches for a long time.
> Java releases are a good example. If an org really needs a Java 22
> feature they can use Java 22 in production - but they are expected to
> upgrade to Java 23, etc. when those versions are released until a new
> Java LTS is released. There are other OSS equivalents. I am not
> talking about Commercial Support contracts - commercial entities are
> very welcome to fill this gap - this does not need to relate directly
> to the FOSS releases from the ASF project team.
>
> If the consensus is to delay Pekko 1.1 until every candidate change is
> made - then fine - but this stops users from using features that are
> ready to try, like the Netty 4 support.
>
> Since Pekko 1.1.0 full release seems like a long way away, it might be
> worth considering mechanisms to release the most useful changes
> earlier - in a way that Pekko 1.0 users can uptake.
>
>
> On Sun, 5 Nov 2023 at 12:59, Matthew de Detrich
> <ma...@aiven.io.invalid> wrote:
> >
> > So my take on this
> >
> > - We should do milestones to solve the general problem you are alluding
> to,
> > i.e. the M1 milestone that you suggest that we vote on (we should also do
> > the M0 milestone which is at the exact moment when a new bump to minor
> > version is done, reasoning why is given in this thread[1]). I would argue
> > that doing an M1 now is a good idea and then an M2 once other critical
> > features land (such as inliner which is mentioned in the below point)
> > - There are some critical features that need to be merged before a
> release
> > of 1.1.0 Pekko Core is ever made (and 1.1.0 Pekko core needs to be
> released
> > before any other 1.1.0 releases for the other modules) due to technical
> > reasons. On the top of my head the critical features so far are the
> > inliner[2] and rolling update migration of Akka to Pekko clusters[3]. I
> > think it's achievable to get [2] and [3] done in a few months time, but
> we
> > would have to focus on getting it over the line ([2] is already "done",
> it
> > just needs a review and testing in downstream modules, [3] likely needs
> > more work and most of all testing so that it works as expected).
> > - Regarding LTS, I don't think we should entertain the idea now. We have
> no
> > idea of what and how an LTS can work and we don't even have the capacity
> > for it. It might even be a thing that LTS's are "someone else's" problem
> > (Pekko is open source after all). I think the most critical thing is
> > sticking to semantic versioning, such an expectation is manageable for us
> > and I would argue is kind of a requirement for large open source projects
> > like Pekko
> > - Fixing the manager name [4] should also be fixed for 1.1.0 (actually if
> > anything this should be fixed for 1.0.x branch as well)
> > - As kind of a stretch goal, sbt-multi-release-jar support for 1.1.0[5]
> > would be awesome as it would unblock a **lot** of things while also
> keeping
> > part of the community happy
> > - Releasing pekko 1.1.0 with the latest sbt-osgi (which apparently fixes
> a
> > lot of pain points versus the current osgi used in Pekko 1.0.x) would be
> > another nice stretch goal, currently there is one issue with duplicate
> > classes but we now have infrastructure set up[6] so that we can properly
> > test such changes.
> >
> > Note that a lot of the underlying reasoning behind my points are also
> > strategic, i.e. keeping features which can be considered critical to
> Pekko
> > and/or current Akka users which don't require to much effort (basically
> > anything that gives a reason for people to use/migrate to Pekko while not
> > breaking the i.e. our bank so to speak). I know that there has been a
> push
> > to do things like drop JDK 8, Scala 2.12, osgi etc etc due to death by a
> > thousand cuts but tbh objectively speaking these issues are not taking up
> > that much time (at least personally by far the largest amount of time
> spent
> > is just overhead of having to do so many releases and validate them,
> really
> > looking forward to the day when we can automate everything with
> > sbt-reproducible-builds/jardiff/create jars in ci etc etc). Pekko 2.0.x
> > series is when we can look forward to drop a lot of this "annoying
> > maintenance" stuff and I would actually strongly argue that at the time
> > when we start looking at Pekko 2.0.x we actually get a better idea of
> what
> > our Pekko users look like, because as has been shown due to the chaos
> > created from the license change very few us had any somewhat realistic
> lens
> > as to how the Pekko community (specifically users) look like, i.e. while
> > the OS would **LOVE** to get rid of JDK 1.8 support it just so happens
> that
> > a lot of people still need to use JDK 1.8 and even though there are
> reasons
> > to move away from 1.8 evidently they aren't relevant.
> >
> > [1] https://lists.apache.org/thread/o494q89hhg64r5nwv4rnq6fsx9zofmny
> > [2] https://github.com/apache/incubator-pekko/pull/305
> > [3] https://github.com/apache/incubator-pekko/pull/765
> > [4] https://github.com/apache/incubator-pekko/pull/587
> > [5] https://github.com/sbt/sbt-multi-release-jar/issues/22
> > [6] https://github.com/apache/incubator-pekko/issues/75
> >
> > On Sun, Nov 5, 2023 at 12:12 PM PJ Fanning <fa...@apache.org> wrote:
> >
> > > The core pekko repo [1] has quite a few changes in its main branch that
> > > are are targeted at a future 1.1.0 release.
> > >
> > > We haven't really agreed on what to do with the code that was already
> > > deprecated in the Akka era and there is also the issue of the
> ApiMayChange
> > > annotations on some of the APIs.
> > >
> > > There are also some new features that developers want to add.
> > >
> > > We don't have a great deal of developer effort available to us.
> > >
> > > I suspect that we need to need to balance the need to release some of
> the
> > > 1.1 changes and then maybe try to make another batch of changes in
> Pekko
> > > 1.2.
> > >
> > > What if we aimed to do a Pekko 1.1.0 release in a few months and said
> that
> > > it was not a Long Term Support release? If we go down this line, we
> would
> > > probably want to have a tentative plan as to when a new LTS release
> would
> > > happen.
> > >
> > > An example of something that would be useful to release would be the
> > > netty4 support. I know that the Apache Flink team would like to use
> this.
> > >
> > > Alternatively, we could do a Pekko 1.1.0-M1 release. I suspect that we
> > > would end up with a fair number of these and the M version number would
> > > discourage uptake (except for testing).
> > >
> > > What are people's thoughts on the options?
> > >
> > >
> > >
> > > [1] https://github.com/apache/incubator-pekko
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > For additional commands, e-mail: dev-help@pekko.apache.org
> > >
> > >
> >
> > --
> >
> > Matthew de Detrich
> >
> > *Aiven Deutschland GmbH*
> >
> > Immanuelkirchstraße 26, 10405 Berlin
> >
> > Alexanderufer 3-7, 10117 Berlin
> >
> > Amtsgericht Charlottenburg, HRB 209739 B
> >
> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> >
> > *m:* +491603708037
> >
> > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>
--
Matthew de Detrich
*Aiven Deutschland GmbH*
Immanuelkirchstraße 26, 10405 Berlin
Alexanderufer 3-7, 10117 Berlin
Amtsgericht Charlottenburg, HRB 209739 B
Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
*m:* +491603708037
*w:* aiven.io *e:* matthew.dedetrich@aiven.io
Re: having non-LTS releases
Posted by PJ Fanning <fa...@gmail.com>.
I have no objections to the general list of changes that we need for
1.1.0. Some of those changes will likely also need backporting for
1.0.x releases.
A 1.1.0-M1 release makes sense. I want to delay it by a week or 2
while we decide what to do about the config logging (recent Akka CVE).
I don't think a 1.1.0-M0 is warranted. This git tag has code that is
very similar to Pekko 1.0.1. I don't see the merit in having multiple
ASF contributors having to review such a release.
I guess it is a separate conversation but there is a fair degree of
resistance to us dropping support for anything. I think we will need
to only drop support if it really makes things much easier for us.
Multi Release Jars seems like a better option than dropping Java 8
support (for instance).
When I say LTS, I mean what versions will get patches for a long time.
Java releases are a good example. If an org really needs a Java 22
feature they can use Java 22 in production - but they are expected to
upgrade to Java 23, etc. when those versions are released until a new
Java LTS is released. There are other OSS equivalents. I am not
talking about Commercial Support contracts - commercial entities are
very welcome to fill this gap - this does not need to relate directly
to the FOSS releases from the ASF project team.
If the consensus is to delay Pekko 1.1 until every candidate change is
made - then fine - but this stops users from using features that are
ready to try, like the Netty 4 support.
Since Pekko 1.1.0 full release seems like a long way away, it might be
worth considering mechanisms to release the most useful changes
earlier - in a way that Pekko 1.0 users can uptake.
On Sun, 5 Nov 2023 at 12:59, Matthew de Detrich
<ma...@aiven.io.invalid> wrote:
>
> So my take on this
>
> - We should do milestones to solve the general problem you are alluding to,
> i.e. the M1 milestone that you suggest that we vote on (we should also do
> the M0 milestone which is at the exact moment when a new bump to minor
> version is done, reasoning why is given in this thread[1]). I would argue
> that doing an M1 now is a good idea and then an M2 once other critical
> features land (such as inliner which is mentioned in the below point)
> - There are some critical features that need to be merged before a release
> of 1.1.0 Pekko Core is ever made (and 1.1.0 Pekko core needs to be released
> before any other 1.1.0 releases for the other modules) due to technical
> reasons. On the top of my head the critical features so far are the
> inliner[2] and rolling update migration of Akka to Pekko clusters[3]. I
> think it's achievable to get [2] and [3] done in a few months time, but we
> would have to focus on getting it over the line ([2] is already "done", it
> just needs a review and testing in downstream modules, [3] likely needs
> more work and most of all testing so that it works as expected).
> - Regarding LTS, I don't think we should entertain the idea now. We have no
> idea of what and how an LTS can work and we don't even have the capacity
> for it. It might even be a thing that LTS's are "someone else's" problem
> (Pekko is open source after all). I think the most critical thing is
> sticking to semantic versioning, such an expectation is manageable for us
> and I would argue is kind of a requirement for large open source projects
> like Pekko
> - Fixing the manager name [4] should also be fixed for 1.1.0 (actually if
> anything this should be fixed for 1.0.x branch as well)
> - As kind of a stretch goal, sbt-multi-release-jar support for 1.1.0[5]
> would be awesome as it would unblock a **lot** of things while also keeping
> part of the community happy
> - Releasing pekko 1.1.0 with the latest sbt-osgi (which apparently fixes a
> lot of pain points versus the current osgi used in Pekko 1.0.x) would be
> another nice stretch goal, currently there is one issue with duplicate
> classes but we now have infrastructure set up[6] so that we can properly
> test such changes.
>
> Note that a lot of the underlying reasoning behind my points are also
> strategic, i.e. keeping features which can be considered critical to Pekko
> and/or current Akka users which don't require to much effort (basically
> anything that gives a reason for people to use/migrate to Pekko while not
> breaking the i.e. our bank so to speak). I know that there has been a push
> to do things like drop JDK 8, Scala 2.12, osgi etc etc due to death by a
> thousand cuts but tbh objectively speaking these issues are not taking up
> that much time (at least personally by far the largest amount of time spent
> is just overhead of having to do so many releases and validate them, really
> looking forward to the day when we can automate everything with
> sbt-reproducible-builds/jardiff/create jars in ci etc etc). Pekko 2.0.x
> series is when we can look forward to drop a lot of this "annoying
> maintenance" stuff and I would actually strongly argue that at the time
> when we start looking at Pekko 2.0.x we actually get a better idea of what
> our Pekko users look like, because as has been shown due to the chaos
> created from the license change very few us had any somewhat realistic lens
> as to how the Pekko community (specifically users) look like, i.e. while
> the OS would **LOVE** to get rid of JDK 1.8 support it just so happens that
> a lot of people still need to use JDK 1.8 and even though there are reasons
> to move away from 1.8 evidently they aren't relevant.
>
> [1] https://lists.apache.org/thread/o494q89hhg64r5nwv4rnq6fsx9zofmny
> [2] https://github.com/apache/incubator-pekko/pull/305
> [3] https://github.com/apache/incubator-pekko/pull/765
> [4] https://github.com/apache/incubator-pekko/pull/587
> [5] https://github.com/sbt/sbt-multi-release-jar/issues/22
> [6] https://github.com/apache/incubator-pekko/issues/75
>
> On Sun, Nov 5, 2023 at 12:12 PM PJ Fanning <fa...@apache.org> wrote:
>
> > The core pekko repo [1] has quite a few changes in its main branch that
> > are are targeted at a future 1.1.0 release.
> >
> > We haven't really agreed on what to do with the code that was already
> > deprecated in the Akka era and there is also the issue of the ApiMayChange
> > annotations on some of the APIs.
> >
> > There are also some new features that developers want to add.
> >
> > We don't have a great deal of developer effort available to us.
> >
> > I suspect that we need to need to balance the need to release some of the
> > 1.1 changes and then maybe try to make another batch of changes in Pekko
> > 1.2.
> >
> > What if we aimed to do a Pekko 1.1.0 release in a few months and said that
> > it was not a Long Term Support release? If we go down this line, we would
> > probably want to have a tentative plan as to when a new LTS release would
> > happen.
> >
> > An example of something that would be useful to release would be the
> > netty4 support. I know that the Apache Flink team would like to use this.
> >
> > Alternatively, we could do a Pekko 1.1.0-M1 release. I suspect that we
> > would end up with a fair number of these and the M version number would
> > discourage uptake (except for testing).
> >
> > What are people's thoughts on the options?
> >
> >
> >
> > [1] https://github.com/apache/incubator-pekko
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > For additional commands, e-mail: dev-help@pekko.apache.org
> >
> >
>
> --
>
> Matthew de Detrich
>
> *Aiven Deutschland GmbH*
>
> Immanuelkirchstraße 26, 10405 Berlin
>
> Alexanderufer 3-7, 10117 Berlin
>
> Amtsgericht Charlottenburg, HRB 209739 B
>
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
>
> *m:* +491603708037
>
> *w:* aiven.io *e:* matthew.dedetrich@aiven.io
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: having non-LTS releases
Posted by Matthew de Detrich <ma...@aiven.io.INVALID>.
So my take on this
- We should do milestones to solve the general problem you are alluding to,
i.e. the M1 milestone that you suggest that we vote on (we should also do
the M0 milestone which is at the exact moment when a new bump to minor
version is done, reasoning why is given in this thread[1]). I would argue
that doing an M1 now is a good idea and then an M2 once other critical
features land (such as inliner which is mentioned in the below point)
- There are some critical features that need to be merged before a release
of 1.1.0 Pekko Core is ever made (and 1.1.0 Pekko core needs to be released
before any other 1.1.0 releases for the other modules) due to technical
reasons. On the top of my head the critical features so far are the
inliner[2] and rolling update migration of Akka to Pekko clusters[3]. I
think it's achievable to get [2] and [3] done in a few months time, but we
would have to focus on getting it over the line ([2] is already "done", it
just needs a review and testing in downstream modules, [3] likely needs
more work and most of all testing so that it works as expected).
- Regarding LTS, I don't think we should entertain the idea now. We have no
idea of what and how an LTS can work and we don't even have the capacity
for it. It might even be a thing that LTS's are "someone else's" problem
(Pekko is open source after all). I think the most critical thing is
sticking to semantic versioning, such an expectation is manageable for us
and I would argue is kind of a requirement for large open source projects
like Pekko
- Fixing the manager name [4] should also be fixed for 1.1.0 (actually if
anything this should be fixed for 1.0.x branch as well)
- As kind of a stretch goal, sbt-multi-release-jar support for 1.1.0[5]
would be awesome as it would unblock a **lot** of things while also keeping
part of the community happy
- Releasing pekko 1.1.0 with the latest sbt-osgi (which apparently fixes a
lot of pain points versus the current osgi used in Pekko 1.0.x) would be
another nice stretch goal, currently there is one issue with duplicate
classes but we now have infrastructure set up[6] so that we can properly
test such changes.
Note that a lot of the underlying reasoning behind my points are also
strategic, i.e. keeping features which can be considered critical to Pekko
and/or current Akka users which don't require to much effort (basically
anything that gives a reason for people to use/migrate to Pekko while not
breaking the i.e. our bank so to speak). I know that there has been a push
to do things like drop JDK 8, Scala 2.12, osgi etc etc due to death by a
thousand cuts but tbh objectively speaking these issues are not taking up
that much time (at least personally by far the largest amount of time spent
is just overhead of having to do so many releases and validate them, really
looking forward to the day when we can automate everything with
sbt-reproducible-builds/jardiff/create jars in ci etc etc). Pekko 2.0.x
series is when we can look forward to drop a lot of this "annoying
maintenance" stuff and I would actually strongly argue that at the time
when we start looking at Pekko 2.0.x we actually get a better idea of what
our Pekko users look like, because as has been shown due to the chaos
created from the license change very few us had any somewhat realistic lens
as to how the Pekko community (specifically users) look like, i.e. while
the OS would **LOVE** to get rid of JDK 1.8 support it just so happens that
a lot of people still need to use JDK 1.8 and even though there are reasons
to move away from 1.8 evidently they aren't relevant.
[1] https://lists.apache.org/thread/o494q89hhg64r5nwv4rnq6fsx9zofmny
[2] https://github.com/apache/incubator-pekko/pull/305
[3] https://github.com/apache/incubator-pekko/pull/765
[4] https://github.com/apache/incubator-pekko/pull/587
[5] https://github.com/sbt/sbt-multi-release-jar/issues/22
[6] https://github.com/apache/incubator-pekko/issues/75
On Sun, Nov 5, 2023 at 12:12 PM PJ Fanning <fa...@apache.org> wrote:
> The core pekko repo [1] has quite a few changes in its main branch that
> are are targeted at a future 1.1.0 release.
>
> We haven't really agreed on what to do with the code that was already
> deprecated in the Akka era and there is also the issue of the ApiMayChange
> annotations on some of the APIs.
>
> There are also some new features that developers want to add.
>
> We don't have a great deal of developer effort available to us.
>
> I suspect that we need to need to balance the need to release some of the
> 1.1 changes and then maybe try to make another batch of changes in Pekko
> 1.2.
>
> What if we aimed to do a Pekko 1.1.0 release in a few months and said that
> it was not a Long Term Support release? If we go down this line, we would
> probably want to have a tentative plan as to when a new LTS release would
> happen.
>
> An example of something that would be useful to release would be the
> netty4 support. I know that the Apache Flink team would like to use this.
>
> Alternatively, we could do a Pekko 1.1.0-M1 release. I suspect that we
> would end up with a fair number of these and the M version number would
> discourage uptake (except for testing).
>
> What are people's thoughts on the options?
>
>
>
> [1] https://github.com/apache/incubator-pekko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>
--
Matthew de Detrich
*Aiven Deutschland GmbH*
Immanuelkirchstraße 26, 10405 Berlin
Alexanderufer 3-7, 10117 Berlin
Amtsgericht Charlottenburg, HRB 209739 B
Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
*m:* +491603708037
*w:* aiven.io *e:* matthew.dedetrich@aiven.io