Как открыть исходный набор плагинов - PullRequest
Новая
       15

Как открыть исходный набор плагинов

1 голос
/ 10 февраля 2010

(мои извинения за неспецифическую формулировку названия вопроса и за свободное использование открытого источника ", когда я на самом деле имею в виду" настройка проекта в SourceForge ")

Недавно мы выпустили 3D-модельер с открытым исходным кодом, который мы продавали в течение нескольких лет, с главной целью сохранить приложение живым. Мы создали магазин на SourceForge.net и сейчас работаем над процессом, который приводит к постоянному потоку бинарных выпусков. Пока все хорошо.

Однако, помимо основного приложения, мы также разработали несколько плагинов (в основном для разных форматов импорта / экспорта). В настоящее время это все еще закрытый исходный код, но мы хотели бы также открыть его (сторонние разработчики плагинов могут позаботиться о своих собственных или пожертвовать и открыть исходный код). Вопрос в том, должны ли наши плагины размещаться как проект самостоятельно или нет?

Опции, которые я вижу:

  1. Добавить источники плагинов в подпапку источников SVN
  2. Создать отдельный проект для набора плагинов
  3. Создать отдельный проект для каждого отдельного плагина

Какая настройка является наиболее практичной и / или распространенной, и как мне работать с двоичными файлами?

Когда приложение все еще было закрыто и было коммерческим, было очень важно, чтобы двоичные файлы плагинов могли обновляться отдельно от основного приложения, но теперь, когда все открыто и часто обновляется, это уже не так уж важно. Кроме того, я не уверен, что хочу побеспокоить разработчиков с помощью множества источников плагинов, которые им абсолютно не нужны, как часть основного проекта.

1 Ответ

2 голосов
/ 14 февраля 2010

  1. Добавить источники плагинов в подпапку источников SVN

    Я думаю, это хорошая идея, если у вас не слишком много плагинов. Вы можете создать структуру папок, как показано в конце моего ответа, чтобы управлять плагинами независимо. Но в этом случае у вас не будет точного контроля над доступом к SVN.

    Преимущество заключается в том, что вам нужно поддерживать только один веб-сайт проекта (если вы вообще его создаете).

  2. Создать отдельный проект для набора плагинов

    Вот, например, Notepad ++ . Их плагины размещены в отдельном проекте SourceForge . Наличие одной страницы загрузки, полной плагинов, и другой страницы загрузки, полной бинарных выпусков вашего программного обеспечения, улучшает читабельность. Но не забудьте упомянуть на веб-странице проекта, что есть отдельный проект плагина.

    Он также имеет то преимущество, что вы можете управлять веб-сайтами проекта самостоятельно. Например, вы можете поручить другим пользователям заботиться о сайте плагинов (если вы найдете кого-то, кто хочет их поддерживать).

  3. Создать отдельный проект для каждого отдельного плагина

    Не очень хорошая идея, обслуживание будет сложнее, так как у вас будет несколько проектов, хранилищ и веб-сайтов проектов.

    Но у него есть преимущество: вы можете более детально предоставить людям доступ к разработке плагинов. Например, пользователям A и B разрешено работать с плагином X, но не с плагином Y. С отдельными SF-проектами это легко сделать. То же самое относится и к веб-сайтам проекта, конечно.

Итак, в заключение я бы сказал, что чем больше вы заботитесь о правах доступа SVN и чем больше у вас плагинов, тем больше смысла создавать один или несколько отдельных проектов для ваших плагинов.

Пример структуры SVN из # 1: 

/modeler
    /trunk
    /branches
    /tags
/modeler-plugins
    /plugin-x
        /trunk
        /branches
        /tags
    /plugin-y
        /trunk
        /branches
        /tags
...