> As pj fanning said, 1.2.x/1.1.x will still be maintained. I am aware of this, but this is besides my point.
What I am saying is that a 2.x.x release is extremely disruptive to not only our users but also our plugin/library ecosystem (it essentially forces the ecosystem to maintain 2 entirely separate branches (one for Pekko 1.0.x and another for Pekko 2.0.x). This means that when we do such a change, we have to do it very sparingly and at a time where we can clump many breaking changes together to minimize disruption i.e. * Dropping JDK 1.8 by moving to JDK 11 * Bumping to next Scala 3 LTS * Possibly dropping Scala 2.12 (note that this list is not entirely inclusive) Put simply, lets not rush a 2.0.x release, I fail to see a pressing need to do so (if anything I see more reasons not to do this). On Sat, Jan 4, 2025 at 12:35 PM kerr <hepin1...@gmail.com> wrote: > > As pj fanning said, 1.2.x/1.1.x will still be maintained. > > 何品 > > > Matthew de Detrich <mdedetr...@gmail.com> 于2025年1月4日周六 18:37写道： > > > I would advise against rushing to do a 2.x.x release, removing things > > is not critical (its just a quality of life change). > > > > The main reason however is if we want to drop support for JDK 1.8 this > > can only happen in a 2.x.x release so its a good idea to reserve the > > 2.x.x when the timing to drop JDK 1.8 is suitable, which is likely > > going to be 1-2 years (we still have critical users that are stuck on > > JDK 1.8, even though people don't like it). Furthermore it makes sense > > to do a 2.x.x release when the next Scala 3 LTS comes out (as it will > > fix a few issues we found in the current 3.3.x LTS). > > > > In summary, these breaking epoch changes shouldn't be rushed, instead > > they should be done sparingly when the situation calls for it and > > pushing for a 2.x.x release just for some quality of life removals > > doesn't pass that bar in my opinion. > > > > On Fri, Jan 3, 2025 at 11:03 AM kerr <hepin1...@gmail.com> wrote: > > > > > > The next version is 1.2 or 2.0.x? > > > if it's 2.0 then we can remove many things. > > > > > > 何品 > > > > > > > > > PJ Fanning <fannin...@gmail.com> 于2025年1月3日周五 17:30写道： > > > > > > > Maybe we could think about a milestone release for 1.2.0 that allows > > users > > > > to try the main branch changes. > > > > > > > > On Fri 3 Jan 2025, 10:06 kerr, <hepin1...@gmail.com> wrote: > > > > > > > > > I'm not using these methods at work, maybe we can backport it if the > > user > > > > > requests? > > > > > > > > > > 何品 > > > > > > > > > > > > > > > PJ Fanning <fannin...@gmail.com> 于2025年1月3日周五 15:06写道： > > > > > > > > > > > My preference is to not merge changes to the internals of the > > concat > > > > > > and flatMap methods into a patch release. We have the 1.2 branch > > line > > > > > > where we can add those. > > > > > > > > > > > > On Fri, 3 Jan 2025 at 04:34, kerr <hepin1...@gmail.com> wrote: > > > > > > > > > > > > > > I would like to have these two PRs in 1.1.3 > > > > > > > https://github.com/apache/pekko/discussions/1566 > > > > > > > > > > > > > > https://github.com/apache/pekko/pull/1623 > > > > > > > https://github.com/apache/pekko/pull/1622 > > > > > > > > > > > > > > 何品 > > > > > > > > > > > > > > > > > > > > > kerr <hepin1...@gmail.com> 于2025年1月3日周五 11:32写道： > > > > > > > > > > > > > > > two fixes for https://github.com/apache/pekko/discussions/1566 > > are > > > > > > ready > > > > > > > > for Code review:) > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > 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
