OberonCore

Я там ссылку дал мимоходом.
Просто увидел, что народ ищет площадку... Ну и предложил redmine, т.к. сам в нем работаю.

От мастер-ветки (сообщества). Или, как минимум, от Fixes.

В общем если мой вариант никому не по нраву, то я за вариант Романа

Вот как я вижу... отличия в том, что не вижу смысла делать отдельную ветку для релизов и делать ветки на разработки фич пока не применены все известные заплаты. Любое исправление делает новый выпуск, зачем кто-то будет качать глючные версии или устаревшую документацию. Совместимость может нарушится, если внедряется новая функциональность или правится конвертер. Куда-то на сайт (сокорее всего это будет oberoncore.org) нужно будет выкладывать стабильные версии в архивах, конечно.

Иван, у меня есть возражение к твоему варианту: ветки от внешних разработок нельзя просто сливать в мастер-ветку - они могут потребовать изменений и, возможно, даже исправлений. Обязательно должна присутствовать магистральная ветка Development, включающая все новшества, не прошедшие всех проверок (соответствие поди даже "спекам", тесты и документация).
То есть, на мой взгляд, внешние ветки (предлагаемые разными участниками, включая OMinc) ничем не должны отличаться от веток FeatureN (и давить авторитетом), сливаемых также в Development. Дело в том, что на некотором этапе всё ещё возможно отклонить слияние некоторой ветки FeatureN (допустим, путём голосования). А если сразу сливать, то позднее будет трудно менять.

Согласен, в чем-то. Вопрос? А может ли эта ветка быть master? Или master как раз за выпуски обычно отвечает? Перерисовал немного рисунок. Роман, еще что у тебя значит ветка fixes? Не совсем понял мысль.

Назначение ветки "мастер" - аккумулировать наиболее стабильные выпуски с последними исправлениями. Их в git можно помечать как "ярлыки" (tag) v0.5.0, v0.5.1 и т.д. Что касается ветки Fixes, то её назначение - это хранение исправлений, если они требуют мало-мальской объём разработки. Мелкие исправления - можно прямо в "мастер". После предварительного тестирования, конечно. Hotfixes - когда направлено на решение какой-то конкретной частной проблемы. Перед тем как выпускать новую версию, переходят в режим "заморозки" слияния новых Feature в Development. Проверяют документацию, работу программы, исправляют и тогда выпускают стабильный выпуск.
Чтобы не повторять уже написанное, направлю на статью A successful Git branching model. Она в большей части соответствует замыслу.

Про версии. Допустим, в статье Branching Strategies with GIT рекомендуют вести нумерацию выпусков таким образом:
x.y.z
x - опубликованная версия
y - номер спринта ("sprint" методологии разработки SCRUM)
z - исправления после публикации

И опять вижу, что ветка oberoncore вливается в ветку "мастер". Почему так? Разве она имеет какое-то авторитетное значение по сравнению с другими ветками? Если кто-то хочет предложить исправление, то это стоит делать не в своей ветке, а прямо в "мастер" или Fixes. Так что любые предлагаемые изменения должны пройти общие проверки на соответствие спецификациям, корректность реализации и т.д., а затем вливаться в Development. В специальной ветке Releases не вижу смысла. Все качают именно "master". Так что, если эта ветка будет сырой, то пользователи будут недовольны.

Роман, да там просто офигенная картинка! Теперь все понял, что ты имел в виду. Если вопрос по итогам головования решится в сторону git, то ты прав, надо будет смотреть главным образом на ту статью.

Я рад, что прояснилось. Хотя, не исключаю, что будут и другие мнения по поводу управления ветками.

Иван, у меня вопрос. Вот у нас есть сейчас ветка dev. Как потом предполагается сливать ее с основной?
Если вдруг окажется что какая-то правка в dev не нужна? (rebase?)

Доводишь до нужного состояния (откатом, если требуется), а потом обычный merge в master.

Нашёл ещё одну статью
A (Simpler) Successful Git Branching Model