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

С выпуском для бета-тестирования мы переместили версификацию SpongeAPI в семантическую версификацию (см. https://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 является stable. Каждый новый коммит в stable вызывает пересборку сайта документации <https://docs.spongepowered.org/>`_. Коммиты в stable чаще всего делаются чтобы описать самый актуальный выпуск 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 также вызывает перестройку более старой версии документации, как и в основной ветке.