On Saturday, April 20, 2013 at 2:14 PM, Thomas Bruederli wrote:

till wrote:

On Saturday, April 20, 2013 at 1:49 PM, Thomas Bruederli wrote:

On Sat, Apr 20, 2013 at 2:17 AM, till <klimpong@gmail.com

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.

Yes, they were back in the SVN times. But even there, it was one repository
holding all plugins not individual repositories for each plugin.

But I don't say that moving the core plugins to composer is a bad idea. So
far my intention of the plugin repository didn't consider that step but it
might.
I think the only downside is:

1) More repositories.
2) Running RoundCube from src would require an `./composer.phar install`
3) Build system/releases would need to be updated as well.

We could include all our vendors as dependencies via composer. Might not be the worst thing and it would cause less noise in the git tree when updates need to be performed?

Till