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]
