Каковы наилучшие практики для выпуска проекта с открытым исходным кодом?[закрыто]

Question

У нас есть довольно классный маленький веб-фреймворк, который мы успешно использовали в десятках клиентских проектов.Мы планируем выпустить это программное обеспечение для сообщества.Тем не менее, я ломаю руки по поводу того, что следует / не следует размещать на странице проекта нового программного обеспечения с открытым исходным кодом.Какими вещами должен обладать сайт?Документы?Вики?Ссылка для скачивания?Что еще?

И связанный с этим, но, возможно, другой вопрос заключается в том, как мы начинаем отмечать номера релизов.Все, что мы используем внутри компании, - это штамп SVN.Есть ли хороший способ определить, когда начинать вызывать что-либо версии 0.9 по сравнению с 1.0 и 1.1 и так далее?

Answer 1

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

• Веб-сайт, который действует как "единое окно" для проекта
• Документы, возможно, в вики-форме
• Исходный репозиторий, позволяющий просматривать, анонимно проверять и аутентифицировать и авторизованные коммиты
• Отслеживание проблем и запросы на новые функции

Что касается номеров версий...Я не думаю, что чей угодно разработал наилучший способ сделать это на данный момент :) После минимума размышлений я бы рассмотрел:

• версия v1.0 должна быть готова к использованию в производстве
• Серьезные изменения номера версии могут полностью привести к потере обратной совместимости (при необходимости - хотя это вряд ли является целью!).
• Незначительные изменения номера версии обычно должны быть в основном совместимы - устаревание, вероятно, лучше, чем удаление / переименование битов API
• Изменения номера версии, превышающие незначительные, должны включать только незначительные функциональные дополнения (если таковые имеются) и исправления ошибок / производительности

Answer 2

Что касается управления версиями, я думаю, что абсолютно лучшим местом для начала является Семантическое Управление Версиями.

Answer 3

Тот самый 0.9 / 1.0 / 1.1 / 1.0.1 / ...маркировка версии предназначена исключительно для маркетинговых целей (в хорошем смысле этого слова).Это позволяет вашим пользователям / заказчикам определить, является ли выпуск основным, второстепенным или содержит исправления ошибок, и считаете ли вы его зрелым или еще нет.

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

Answer 4

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

Назовите эту первую версию 0.1.Это связано с тем, что у вас еще нет документов для поддержки проекта.

Затем дыши.

Затем начните просматривать документацию, например, wiki.Как только вы все это рассмотрите на базовом уровне детализации и сочтете, что релиз готов к некоторому прайм-тайму, переходите к версии 1.0 и начинайте предоставлять двоичные загрузки.

Answer 5

Убедитесь, что вы подумали о лицензии на исходные тексты.

Когда я смотрю на проект с открытым исходным кодом, одна из первых вещей, которые я проверяю, - это лицензия.Если лицензия не соответствует стилям GPL2 / GPL3 / BSD или подобным, для меня это демотиватор.

Лицензия означает, что люди будут с ней делать, как она может расти и в какой степени она принадлежит корпорации, выпустившей ее.Поскольку, выбирая open source, я стараюсь не зависеть от корпораций (которые зависят от своих акционеров), я действительно выбираю действительно бесплатное программное обеспечение.

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

Смотрите больше на свободное программное обеспечение и открытый исходный код определения FSF.

Answer 6

Взгляните на GitHub или Google Code.они обеспечивают очень хорошую отправную точку для собственных проектов с открытым исходным кодом.Вы можете описать свой проект, задокументировать в wiki, использовать git или svn в качестве своего репозитория и предоставлять загрузки вместе с отслеживанием проблем и управлением несколькими разработчиками.Отличные готовые среды, из которых можно извлекать уроки и использовать их.

Для номеров выпусков:Я не рекомендую 0.9 или что-то подобное для предварительных выпусков.В чем причина?А как насчет версии 1.9?Является ли это 9-м подрелизом основного выпуска 1 или это последний предварительный выпуск выпуска 2?Мой стандарт выпуска описан здесь: http://code.google.com/p/tideland-eas/wiki/ReleaseStandard.Я использую схему с тремя числами: major, minor и fix, вместе с кодом состояния, alpha, beta, gamma и датой выпуска.Таким образом, я могу легко обрабатывать несколько выпусков параллельно.

Надеюсь, это поможет.

муэ