If there are no objections, I would like to press on with an RC for v1.1.3. The milestone [1] has the changes.
I would prefer not to add more to the patch as it already has a few changes. If a high impact bug turns up, then I'd happily consider it but the existing PRs look like nice to haves and not high impact issues. My preference for the nice to haves is for us to do a v1.2.0-M1 release in the next fews weeks or months. There is an ongoing discussion about making bigger changes like removing deprecated code and dropping support for older Java and Scala versions. That would delay the M1 and maybe we should hold off on dropping stuff until we have a bigger discussion [2]. [1] https://github.com/apache/pekko/milestone/13?closed=1 [2] https://lists.apache.org/thread/rzylygg5jrh5dhgbpczr6p7nzgq56vy9 On 2024/12/17 19:17:22 PJ Fanning wrote: > There were problems with the Pekko/Akka cluster support so we need to delay > the release. There is ongoing work for this. We'll probably try to put a > release together in January. > > On 2024/12/12 11:05:24 PJ Fanning wrote: > > We only need PR1578 if we want to support Akka nodes that are running > > with versions older than 2.6.5. The problem is that if we sort out the > > fromBinary, we may also need to update toBinary (I haven't done a > > thorough analysis of toBinary). Do we really want to support Akka pre > > v2.6.5? > > > > https://github.com/apache/pekko/pull/1578 > > > > I'm happy to backport PR1423 to v1.0.x branch if the feeling is that > > we want Akka users to go to Pekko 1.0.x first. > > > > https://github.com/apache/pekko/pull/1423 > > > > On Thu, 12 Dec 2024 at 10:38, Arnout Engelen <enge...@apache.org> wrote: > > > > > > On Wed, Dec 11, 2024 at 1:52 PM PJ Fanning <fannin...@apache.org> wrote: > > > > I think we have the Pekko/Akka mixed cluster changes that we need and > > > > they are ready for release. > > > > > > Don't we still need https://github.com/apache/pekko/pull/1578 ? > > > > > > > I updated the doc relating to this and include the Known Issues that > > > > have come to light recently. > > > > https://cwiki.apache.org/confluence/display/PEKKO/Pekko+Akka+Compatibility > > > > > > Great! > > > > > > > Pekko 1.1 has an additional change to support Akka migrations so I > > > > think it is best to focus on this release over a new Pekko 1.0.4 > > > > release. Another option might be to backport the additional PR that > > > > never made it into a Pekko 1.0.x release. > > > > https://github.com/apache/pekko/pull/1423 > > > > > > > > The docs are now updated to say that Pekko only works with Akka nodes > > > > of version 2.6.5 and above. The details of why are in the > > > > Pekko+Akka+Compatibility doc. > > > > > > This question boils down to: do we want to tell people who are migrating > > > to > > > a) first migrate to Pekko 1.0.x and then to 1.1.x, or > > > b) migrate directly to 1.1.x? > > > > > > Telling them to migrate directly to 1.1.x may be more difficult as > > > we've updated dependencies there, diverging more from Akka. On the > > > other hand, the number of cases that *really* need a zero-downtime > > > cluster migrations is likely small, so it makes sense that that will > > > be more complicated. I'm in favour of focusing on 1.1 (telling people > > > to migrate directly to 1.1.x instead of going through 1.0.x) > > > > > > > > > Kind regards, > > > > > > Arnout > > > > > > > On 2024/11/27 14:37:36 Arnout Engelen wrote: > > > > > I don't think there needs to be a particular rush, we can ask people > > > > > who want to migrate clusters from akka to pekko to update to 1.0.x > > > > > first. (I thought we discussed that that might be the > > > > > wise/conservative thing to do anyway, but can't find a reference right > > > > > now. If so we should mention that at > > > > > https://cwiki.apache.org/confluence/display/PEKKO/Pekko+Akka+Compatibility). > > > > > > > > > > It might be nice to do a release. I'm ok with these changes going into > > > > > 1.1.3. https://github.com/apache/pekko/discussions/1566 might be worth > > > > > looking into before we do, but we shouldn't let it hold things up. > > > > > > > > > > > > > > > Kind regards, > > > > > > > > > > Arnout > > > > > > > > > > On Tue, Nov 26, 2024 at 10:25 PM PJ Fanning <fannin...@apache.org> > > > > > wrote: > > > > > > > > > > > > Can I ping everyone on this? We have a bug that I think we want to > > > > > > release the fix for. > > > > > > > > > > > > https://github.com/apache/pekko/pull/1562 > > > > > > > > > > > > I have also tested building various Pekko Persistence > > > > > > implementations (JBDC, Cassandra, etc.) and found that they are > > > > > > still build ok with the latest Pekko snapshots despite the changes > > > > > > in: > > > > > > > > > > > > https://github.com/apache/pekko/pull/1518 > > > > > > > > > > > > I'm still on the fence as to whether 1518 should be removed and > > > > > > delayed till a Pekko 1.2.0 release. If there are no strong > > > > > > objections, it still feels better to just proceed with the 1.1.3 > > > > > > release and include this change. > > > > > > > > > > > > > > > > > > On 2024/11/10 12:54:42 PJ Fanning wrote: > > > > > > > Hi everyone, > > > > > > > > > > > > > > I think it would be a good idea to release v1.1.3 of the core > > > > > > > Pekko libs. > > > > > > > > > > > > > > The milestone is: > > > > > > > https://github.com/apache/pekko/milestone/13?closed=1 > > > > > > > > > > > > > > This revert fixes an edge case. > > > > > > > https://github.com/apache/pekko/pull/1526 > > > > > > > > > > > > > > There are a couple of new methods in pekko-persistence-typed but I > > > > > > > think they are ok. > > > > > > > https://github.com/apache/pekko/pull/1518/files#diff-9c896065f6ff551b450ec29d1e606971183c36dd03799330b3494372359ddaeb > > > > > > > > > > > > > > Does anyone have any objections? I can release manage but if > > > > > > > anyone > > > > > > > wants to volunteer, I can assist. > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > > > > > > > For additional commands, e-mail: dev-h...@pekko.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > > > > > > For additional commands, e-mail: dev-h...@pekko.apache.org > > > > > > > > > > > > > > > > > > > > > -- > > > > > Arnout Engelen > > > > > ASF Security Response > > > > > Apache Pekko PMC member, ASF Member > > > > > NixOS Committer > > > > > Independent Open Source consultant > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > > > > > For additional commands, e-mail: dev-h...@pekko.apache.org > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > > > > For additional commands, e-mail: dev-h...@pekko.apache.org > > > > > > > > > > > > > -- > > > Arnout Engelen > > > ASF Security Response > > > Apache Pekko PMC member, ASF Member > > > NixOS Committer > > > Independent Open Source consultant > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > > > For additional commands, e-mail: dev-h...@pekko.apache.org > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > > For additional commands, e-mail: dev-h...@pekko.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > For additional commands, e-mail: dev-h...@pekko.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org For additional commands, e-mail: dev-h...@pekko.apache.org
