I’d split it up, like we did with
Kaleidoscope too, because that makes it easier to introduce and maintain a new device easier: you don’t have to get the code merged anywhere, which makes it easier to do faster iterations in the beginning, while still not inconveniencing users.
For example, lets say I want to add support for a custom keyboard, nicknamed
Twins (for no particular reason at all, no, definitely no reason). This is a custom keyboard no-one else has, and no-one is likely to build one either, let alone mass-produce. For
Kaleidoscope, this means I’ll create a
Kaleidoscope-Hardware-Twins plugin, that contains the necessary bits. I don’t have to merge it into any master repo, and I can use stubs from day one, for parts that are not implemented yet. It’s convenient to develop, straightforward to work with, and so on. There is also no reason this should be merged anywhere, because this is a one-of-a-kind thing.
Obviously, I’d want Chrysalis to support this keyboard too. For similar reasons (being a one-of-a-kind keyboard), having explicit support for it in the main repo does not make much sense. No-one but me can test it, no-one else is interested in maintaining it. It would just be a burden for everyone else to carry mostly unused code around.
This is why pushing hardware stuff to plugins is sweet. Makes it easier to add and maintain device support. From a user perspective, initially, this may mean some extra work of installing the plugins (though we can do what we for
Kaleidoscope with the
Arduino-Boards repo, and include some of the hardware bits in a collection of “recommended default set of available plugins”), but later on, we can move towards a way to install plugins on-demand. Along with their dependencies, and so on. (That would be useful for
Kaleidoscope too, by the way.)
I hope the intent is clear from this description