Система управления версиями и расположение ветвей репозитория

С выпуском для бета-версии мы перенесли SpongeAPI в семантическое управление версиями (см. http://semver.org/). Это изменение означает, что каждый раз, когда мы делаем выпуск, мы должны увеличивать версию в соответствии с правилами semver.

SemVer

SemVer использует схему `` X.Y.Z``, где X это major версия, Y это minor, а Z — версия patch. Версия, содержащая изменения, которые не являются обратно совместимыми, должна быть на одну версию major выше предыдущей версии. Если есть только новые функции, которые по-прежнему совместимы с предыдущими версиями, то новая версия будет на одну minor версию выше предыдущей версии, и если выпуск содержит только исправления, то будет увеличена только версия patch.

Это означает, что, например, 3.2.0 полностью совместим с 3.0.0, в то время как 4.0.0 не является бинарно совместимой с 3.0.0. 3.1.0 и 3.1.2 полностью взаимозаменяемы, не считая исправленных ошибок.

Расположение наших веток (описанных ниже) предназначено для содействия этому процессу, позволяя нам выпускать небольшие релизы без серьезных изменений и заставляя включать их в основной выпуск. Этот вид ветвления применяется к репозиториям SpongeAPI, SpongeCommon, SpongeForge и SpongeVanilla, но не к SpongeDocs.

SpongeAPI, SpongeCommon, SpongeForge и SpongeVanilla

Ветвь Bleeding

Ядром наших репозиториев является ветка bleeding. Почти все изменения будут добавлены к bleeding, включая новые функции, изменения и исправления. Версия bleeding всегда будет следующей основной версией с добавлением -SNAPSHOT (прим. 6.0.0-SNAPSHOT), чтобы обозначить, что она еще не окончательная сборка и может быть изменена.

Основной причиной наличия ветви bleeding является наличие полигона для внесения изменений. Даже опытные члены команды Sponge могут случайно вызвать сбои в работе или пропустить ошибку. Секция bleeding будет протестирована людьми из сообщества, которые хотят получить самую последнюю версию, а это значит, что мы можем гораздо быстрее исправить возникающие ошибки.

Стабильные ветви

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

Когда придет время выпуска основной версии, новая ветка stable-x будет создана из bleeding, где x это новая основная версия — например, stable-5. bleeding будет соответствующим образом обновлен до следующего крупного релиза, как описано выше.

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

Ветви функциональностей (Feature Branches)

Новые возможности или изменения должны быть созданы в ветке feature/foo или fix/bar. Это должно быть основано на самой последнем коммите bleeding. Единственное исключение в том случае, если изменения несовместимы с нарушающими изменениями bleeding, в этом случае вы должны основываться на соответствующем stable-x. В своем pull-request запросе вам необходимо указать, почему ваше изменение не может быть включено в bleeding — например, исправление ошибки в функции, которая была удалена Mojang в более поздней версии.

Если внесенные изменения не нарушают предыдущий релиз, команда Sponge также может включить некоторые изменения (cherry-pick) в одну или несколько stable ветвей, предполагая, что после слияния изменений в bleeding проблем не возникнет.

SpongeDocs

Сами SpongeDocs являются неверсированными в соответствии с нашей философией, так как они никогда не будут закончены, а будут постоянно меняться. Однако они нацелены на определенную версию API, как правило, на самую последнюю версию SpongeAPI.

Основная ветвь

Основной веткой для SpongeDocs является master. Каждый новый коммит в master вызывает перестроение веб-сайта SpongeDocs. Коммиты в `` master`` обычно делаются для документирования самой последней версии SpongeAPI или для исправления незначительных ошибок.

Ветви функциональностей (Feature Branches)

Всякий раз, когда описывается новая функция, старые тексты обновляются или изменяются или документы реструктурируются, это делается в ветке feature/foo или fix/bar. Затем эти ветви будут пересмотрены и, если они будут признаны завершенными, могут быть объединены.

Ветвь функциональностей может быть объединена только с главной, если внесенные в нее изменения/дополнения правильны в отношении SpongeAPI, на которую в настоящий момент направлен SpongeDocs. Любые функциональные ветви, описывающие функции, еще не включенные в релиз, остаются несвязанными до выпуска соответствующей версии API и становятся новой целевой версией для SpongeDocs. Однако команда Docs может собирать дополнения для конкретной версии в одной ветви.

Ветвь релиза

SpongeDocs использует ветви release/x.y.z для публикации документации для более старых версий API, таких как API 3.1.0. Более старые выпуски API доступны в соответствующих ветвях. Всякий раз, когда выпускается новая версия API, команда документации создают новую ветвь release/x.y.z и затем перемещает master на новую версию API. коммит в ветвь release также вызывает перестройку более старой версии документации, как и в основной ветке.