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?

Reply via email to