As a preliminary step could we have a script to verify the function calls in each addon are still valid on a daily basis.
Just iterate across every function definition and validate against the latest repo to check if the variables/structure of the calls are correct? If any breakages are found send en email to the addon maintainers so they have a headsup on what they need to fix. Patrick On Fri, February 22, 2013 4:59 pm, Chad Fraleigh wrote: > On Mon, Feb 18, 2013 at 9:12 PM, Campbell Barton <[email protected]> > wrote: >> On Mon, Feb 18, 2013 at 7:38 PM, Chad Fraleigh <[email protected]> >> wrote: >>> This question probably has already be discussed, but are there any >>> plans to implement an addon deployment like mozilla applications >>> (firefox/thunderbird/seamonkey 2.x) uses where the client (blender) >>> can just browse a central http://addons.blender.org/ site (or >>> something) and with a click or two, install/upgrade what they want. >>> Then there would be few (or none) bundled by default. And if they are >>> bundled, they would act as defaults (i.e. only if that plugin hasn't >>> already been installed for the user, regardless of versions). Then >>> newer addons could be published without needing to align with the >>> blender release cycle. >>> >>> Making sure already installed ones are compatible with potential >>> internal blender changes will still be an issue. But if addon >>> deployers (assuming more than just core blender developers could >>> maintain these addons) would keep what versions of blender that each >>> of their addons (by version) are compatible with. From that a single >>> metafile could be generate automatically/daily/whatever for blender to >>> download/check (with user consent) automatically when it detects a >>> different blender version installed. >>> >>> Maybe .bap (Blender Addon Package) files (which are just zipfiles)? >>> =) >>> >>> And I assume python can be used [client side] to do all this, as-is, >>> and that resorting to trying a [much?] harder C implementation could >>> be avoided. >>> >>> >>> -Chad >> > >> Gaia Clary has a working online addon browser, I'm not sure of the >> status right now though of if she intends to further develop it. > > Is there a link to a demo somewhere that would give an idea of what > features it has? > > >> As I see it. the issue with this is we end up having to write our own >> package manager which is simple to begin with but gets complicated >> fast >> (consider existing extension repositories of mature applications - >> firefox and eclipse for example). > > Are you specifically referring to the client side, server side > repository data (no UI), server side HTML repository browser > (read-only), and/or server side package CMS? The first two I expect > are simple enough, the third more effort, and the last being the > hardest (especially if updatable by "general users"). > > >> So we need someone to write & maintain it, then buy-in from existing >> extension developers. > > As a transition, the core addons could stay in subversion with maybe > just some metadata files added, but otherwise be maintained nearly the > same. > > >> Since we already have a hard time maintaining existing addons in >> subversion, I'm not sure this would be a success at the moment. > > Is this because there aren't enough core developers to maintain them > (including the contrib ones), or simply that they are "second class" > code that is mostly ignored until someone wants to improve one (or > something unexpectedly breaks due to an internal application change)? > > If it is a developer resource problem, then if the contrib ones could > be more directly maintained by their contributors (instead of being > quasi-part of blender's code), in the long term it could reduce the > blender side maintenance (just like google doesn't "maintain" > publisher's individual android apps much beyond allowing them > add/update them on the google play site). If mainly for other reasons, > then I guess there isn't as much of a maintenance benefit beyond > offloading some contrib related codebase change requests. > > Also, I'm guessing that the addons, as-is now, aren't generally [some > form of] unit test friendly to allow automated testing before each > release (assuming manually testing all of them is even done now). > > > I threw together a document (~14k text) of how I would envision (give > or take) a [remote] repository based addon/package system. While I'm > not sure how it compares to that addon browser that was already done, > I could post it (after I clean up the formatting a little) to see what > everyone thinks (that feels like doing some "lite reading" ;) ). > > > -Chad > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > -- Patrick Shirkey Boost Hardware Ltd _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
