This week-end, refactoring Zed code, I've edited in //:
During that experience, at one moment rKHEALTH wanted rKOT 0.x.y but I was also using rKREPORT, which wanted rKOT 0.x'.y'. And I was providing for all dev-main, to be able to have a symlink in Composer for them.
That's an awful experience to need to work with tightly coupled libraries. Order of commits also matters (first rKOT, then tag and bump version, then implement in other lib).
Those problems COULD PERHAPS be solved in a monorepo.
That could also bring the benefit of avoiding issues with repo setup.
Plan
- Rename legacy keruald/keruald into a kerual/oldcore on GitHub (hmmm we've also this repo here under rK), that one isn't interesting anymore.
- DevCentral Diffusion: Create rK as a monorepo. Tomono can help for that.
- DevCentral Diffusion: Block push to other repos. Switch from hosted to observe from a server which will do the split.
- Use split.sh, git-subsplit or monorepo-builder to create split subtrees automatically (through a Jenkins CD job?)
- Setup CI on Jenkins with a Jenkinsfile.
Revert plan
If we don't like this experiment:
- Jenkins CI: transform the pipeline into a template to create one pipeline per repo
- Jenkins CD: delete, as we won't need to split anymore
- DevCentral Diffusion: revert to normal hosted repo, with GitHub as mirror, then archive the monorepo
First candidates
All the ones above + rKCMD and the future splits from Zed: keruald/session, keruald/smartline, keruald/l10n