You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This project can only reach its full potential through the implementation of a plugin model. That said, the fact that this involves configuration for deployment means there are security implications. A pretty careful approach to facilitating a plugin model is warranted.
There are other, simpler 1.0 tasks to close out. But closing those out after implementing the plugin model will help make sure that new architecture is done appropriately.
After implementing the internal plugin model, we should do as much refactoring as possible before splitting out into external plugins. Right now, any change that affects both a plugin and core is contained in a single release. After separating into external plugins, that would require at least two releases, and four releases if it affects core and all plugins. The benefit will be that individual plugins can be developed and released on their own schedule from that point forward.
Complete as much internal refactoring as is clearly needed. Once plugins are separated, any changes that affect plugin and core will require at least two releases; four releases if it affects all platforms.
Move this project to an org.
Implement an external plugin model, where plugins are pulled out into separate repos. Unit tests should work in the standalone repo, integration tests and e2e tests should only run when core is available. See Move plugins to separate repos #361.
Refine to the point it can support third-party plugins with a clear integration process.