I really believe this is the best approach. For the end-user they get a system that's highly customizable, adding only what they want or need. For developers, especially core, testing becomes easier and timelines are less dependent on outside sources. Add-on developers will have to understand that testing and development may be a one person shop more than before. Basically the strength of the add-on idea will show how many people are willing to test and help.
A couple things to note for all of us as we grow, test and contribute to XBMC. Question 1: From Ned's team, will you all consider what is core functionality by version or by road map? I mean will your team say for Frodo we will slice off A, B, C from "core" to become an add-on, or will your team say that a road map will say A and C will become add-ons in the next version, and then in the subsequent version, B will become an add-on. I know it sounds like semantics but there are differences.
Question 2: Now that a version control document has been set by Question #1, what things become the main add-on repository? (Even deeper, could this main repo be an add-on in itself so that core is not dependent on repo add-ons for releasing versions?) Also, I know a wiki is available for unofficial repos
, so is it possible to build an add-on scraper to hunt for the unofficial repos?
(2012-03-27 21:29)Ned Scott Wrote: Anything that is currently an add-on and works great as an add-on will stay as an add-on. More things that are in XBMC core will eventually break away and also become add-ons. They might be included-by-default add-ons or not, but they will still be add-ons. This more modular approach to XBMC will allow updates for things between major releases, decrease bloat, decrease settings bloat, decreased application size, etc.