candy-chat/candy-plugins — pull request #108 by benlangfeld (2014-08-08 22:38:22+00:00)
Title: Plugin versioning/testing/packaging

Note: Throughout I am assuming that Candy complies with SemVer.

This is the current situation with Candy plugins:

* Plugins cannot specify a version of Candy core to depend on, either if they require particular Candy features or are only compatible with an old version's API.
* Plugins have version numbers, but these are not regularly updated and don't have semantic value.
* Plugins are not packaged for Bower. Including plugins within an application requires one of the following approaches:
* Use this repo as a git submodule and upgrade all modules in lock-step
* Vendor individual plugins as required
* Plugins are not tested

Some of these things could generally be improved, and some will specifically hurt us as we make backward-incompatible changes to Candy core leading up to v2.0, such as event namespaces.

I see two broad outlooks for candy-plugins, and propose two different sets of solutions for some of the above problems:

1. candy-plugins should be considered a package.
1. Plugins should remain in this repo.
2. `CandyShop` has grown up as a container name for plugins. This should be formalised and used as the name for the package of plugins in this repo (and maybe the repo name?).
2. CandyShop should be packaged for Bower and released together.
3. CandyShop should have a version number, rather than individual plugins, reflecting changes in any plugin.
4. CandyShop should have an appropriate dependency on Candy core.
5. CandyShop should have a test setup in-line with Candy core and each plugin should have its own test coverage.
2. candy-plugins should be considered a collection of packages
1. Plugins should be stored in individual repos, either under the candy org on Github or elsewhere.
1. Individual plugins should be packaged for Bower and released individually.
2. Individual plugins should have their own version numbers which should reflect their own changes.
3. Individual plugins should have an appropriate dependency on Candy core.
4. Individual plugins should make their own testing arrangements.

I much prefer the bundled approach for the following reasons:

* It's easy to discover new plugins as they're kept together.
* Standards for versioning/testing/packaging can be enforced more uniformly and only need doing once.

The downside to the bundled approach is potential dependency conflicts. A user might want Plugin A @ v1.0 but Plugin B @ v2.0, or worse, might want to upgrade Candy core but is held back by compatibility of a plugin they don't even use. I think this can probably by mitigated by trimming the set of plugins down a little (removing duplication), improving the standard of each and simply moving fast on incompatibilities.

I'm happy to bootstrap option 1 if you're in agreement @mweibel / @pstadler.

/cc @melissanoelle