> Yes I understand this concern, the only argument I can bring forward to quell this is that we don't do that many releases of pekko-connectors as it stands right now anyways, something like 80% of the pekko connectors have been largely entirely unchanged (such as Apache Kudu) and so we shouldn't get an incredibly steep increase in release cadence.
Of course we will get a temporary increase in voting for the first version of 2.0.0, but after that it shouldn't be that much more than what we have now. On Thu, Dec 4, 2025 at 12:52 AM Matthew de Detrich <[email protected]> wrote: > > The biggest issue is the vote requirements for releases. It's already > onerous enough with the number of repos that we have. > It's falling to a small number of contributors to do the releases and > reviews. > It's also less confusing to have fewer version numbers to worry about > and document. > > Yes I understand this concern, the only argument I can bring forward to > quell this > is that we don't do that many releases of pekko-connectors as it stands > right now > anyways, something like 80% of the pekko connectors have been largely > entirely > unchanged (such as Apache Kudu) and so we shouldn't get an incredibly steep > increase in release cadence. > > Would also love to get thoughts of others. > > On Thu, Dec 4, 2025 at 12:34 AM PJ Fanning <[email protected]> wrote: > >> The biggest issue is the vote requirements for releases. It's already >> onerous enough with the number of repos that we have. >> It's falling to a small number of contributors to do the releases and >> reviews. >> It's also less confusing to have fewer version numbers to worry about >> and document. >> >> On Wed, 3 Dec 2025 at 14:26, Matthew de Detrich <[email protected]> >> wrote: >> > >> > This has been talked about before but since we are going ahead in the >> early >> > stages of a 2.0.0 release, what are peoples thoughts of splitting out >> the >> > pekko-connectors? >> > >> > As a recap, the core problem we have with pekko-connectors right now is >> > that all of them sit in a massive monorepo, this presents the following >> > issues >> > >> > - We can't make exceptions to specific pekko connectors for using JDK >> > versions newer than the one used in pekko core if it calls for it (i.e. >> the >> > pekko connector has a core underlying library that mandates a newer JDK >> > version). We dealt with this issue frequently for Pekko 1.x series. This >> > problem would be entirely solved if the pekko connectors were split out >> > into their own modules >> > - bugs/fixes/features are slower to be released than desired as >> currently >> > we don't want to "waste" a release when there are just one or two new >> > features considering its an entire elease of Pekko connectors as a >> whole. >> > As a result we tend to delay releases to wait for features to pile up >> > - It breaks our currently well established/followed semver >> > guidelines/expectations as we just end up making redundant releases for >> > entire pekko-connectors artifacts with basically no changes >> > >> > The major obvious downside of splitting out the repositories is the >> initial >> > massive uptick in overhead of having to deal with these extra repos. As >> it >> > stands right now its not too problematic as the feature/bugfix churn of >> > Pekko connectors modules is not that high, the biggest effort would be >> the >> > initial work in setting up the repos. >> > >> > In my view the most effortless way to deal with this would be that we >> would >> > continue developing 2.0.0 series as we currently do with milestones >> > (including the current pekko-connectors monorepo), but when we decide >> to do >> > an actual full release of pekko-connectors 2.0.0, instead of releasing >> the >> > monorepo we would instead start creating a separate github repo of the >> > module we want to release (which would largely involve copying existing >> > code in the monorepo with a slightly altered folder structure). This >> > strategy allows us to prioritize the pekko-connectors modules which see >> the >> > most use, and it also avoids any additional friction with the current >> Pekko >> > 2.0.0 milestone work that we are doing. >> > >> > Thoughts? >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >>
