[DOC] Why we deciced to make RR2 as the library and where is the RR2 binaries?

[rustatian]

As you can see now, RR2 does not contain a cmd folder with main.go; thus, RR2 can not be run as a standalone program. Instead, RR2 is a runtime for the plugins and PHP processes management. We did so because of circular dependencies. Imagine the following concept:

1. We have an external plugin (let it be: https://github.com/temporalio/roadrunner-temporal - RRT).
2. RRT plugin need to have pkg/pool inside, thus have import like import "github.com/spiral/roadrunner/v2/pkg/pool.
3. But, in turn, RR2 also has the import like: "import github.com/temporalio/roadrunner-temporal in the cmd folder.
4. As a result, we have a circular dependency between RR2 <-> RRT.

How to deal with that problem? We tried the following ways:

1. Create a separate repo for all plugins. Versioning separately. Problem: not all the plugins are free from RR. Thus we are returning to the circular dependencies.
2. Separate repo + separate go.mod for each plugin. Very very very hard to properly set versions. For example: logger depends on config; thus, we should set the config version first. The problem comes when we have 15+ plugins... And also, not of them are free from RR, so, back to circular dependencies.
3. 2 branches in the RR repository. One - master without cmd, and one is roadrunner-binary with binaries. But that also confusing because we should have 2 types of releases. First - just tag for the RR library, second - actual release with binaries. This solution solves problems with circular dependencies but leads to mistakes and confusion in the releases. For example, release 2.0.1 without binaries (tag) and 2.0.2 with binaries. What release to use? May I use 2.0.1? What the difference between them? So, a lot of questions.

When I learned all of this stuff, we decided to leave RR2 as just a library for the plugins. And I introduced a separate repository roadrunner-binary, which has the purpose of:

1. Store public releases of the Roadrunner 2 (including Docker images).
2. Store the CLI for the Roadrunner library.

How to use all this stuff:

1. Developers of the plugins:
   1.1 Import the RR2 library and use abstractions from it.
   1.2. Add your brand new plugin to the roadrunner-binary repo as just 1 import line or to your personal clone of it; that's it.
2. PHP side:
   2.1. $ vendor/bin/rr get command pointing to the roadrunner-binary repository, so no changes from the PHP side.

[jwillp]

In light of this, maybe the documentation at https://roadrunner.dev/docs/intro-install should be updated to reflect these changes since the releases page link still points to this repository.

[litan1106]

Yes, ran into the outdated doc too.

[rustatian]

Yes, ran into the outdated doc too.

That was fixed. The link points to the roadrunner-binary repository.

[rustatian]

In light of this, maybe the documentation at https://roadrunner.dev/docs/intro-install should be updated to reflect these changes since the releases page link still points to this repository.

Hey @jwillp. You are totally right, nice catch. Will do 👍🏻