On Saturday, April 20, 2013 at 1:49 PM, Thomas Bruederli wrote:
> On Sat, Apr 20, 2013 at 2:17 AM, till <[email protected] > (mailto:[email protected])> wrote: > > > > On Saturday, April 20, 2013 at 1:35 AM, rodrigo wrote: > > > > Is there any particular reason the default set of included (but not > > activated) plugins has not been separated out from the main repository > > into repositories of their own? I would even argue that skins, aside > > from the default, should be separate repositories. My group manages our > > installation with git and it would make my life a ton easier if this > > were the case. > > > > I don't remember when they were put back into the "master". They used to be > > more separate. > > > > > Wrong. Plugins developed and maintained by the Roundcube developers > always have been part of the master git repository together with the > code code. The planned composer-based plugin repository is meant for > 3rd party plugins. The main goal of that repository is to allow plugin > developers to publish their modules on a centralized platform and > allow Roundcube sysadmins to pull them into their local installations. > That isn't necessary for core plugins because they're already part of > the distribution package. > > The plugins were in their own tree in SVN. Maybe that's what I meant. > > > > We can easily spin them off with a git subtree split — also keeping the > > history, etc.. But yeah, in its current state composer requires individual > > repositories and so on. I guess this is more or less of question of handling > > these externals. > > > > I saw an answer to "[RCD] update.sh (http://update.sh) clobbering custom > > plugin configs in > > main.inc.php?" earlier today, suggesting that a config file within the > > plugin should be edited. Plugins are basically vendor code, wouldn't it > > make more sense to make a plugin_name.inc.php within /config, and have a > > plugin standard (in the form of a config grabber method) that grabs the > > appropriate config file? This way, the plugin could be updated by > > composer or git, and there'd be no worry about overwriting configs, or > > editing vendor code. It'd encourage plugin writers to keep their config > > separate from the roundcube config, because there'd be an easily > > accessible function for it. > > > > > We already have that separation but not in the centralized /config > directory but in the individual plugin folders. And this basically > should survive an update via composer. > > > I'd also like that. I think up until now the configuration part hasn't seem > > too much love and is very legacy. But if you have ideas, feel free to bounce > > them around. :) > > > > > There's a general refactoring of the config system planned: > http://trac.roundcube.net/ticket/1487311 > Please add your inputs and comments there. > > ~Thomas > _______________________________________________ > Roundcube Development discussion mailing list > [email protected] (mailto:[email protected]) > http://lists.roundcube.net/mailman/listinfo/dev > >
_______________________________________________ Roundcube Development discussion mailing list [email protected] http://lists.roundcube.net/mailman/listinfo/dev
