System wersji i układu repozytorium Branch

Wraz z wydaniem wersji beta przenieśliśmy wersjowanie SpongeAPI do Semantic (patrz http://semver.org/). Zmiana ta oznacza, że za każdym razem, gdy tworzymy nowe wydanie to przyrasta numer na zasadach semver.

SemVer

SemVer używa schematu X.Y.Z, gdzie X jest dla głównych wersji, Y dla drobnych i wreszcie Z czyli wersja poprawkowa. To wydanie zawierające zmiany, które nie są zgodne backwards muszą być o jeden od główny większe o jeden. Jeśli tam są tylko nowe funkcje, które nadal są kompatybilne wstecz, to nowe wydanie będzie o jeden drobny większy niż poprzednie wydanie, i jeśli wydanie zawiera tylko poprawki błędów to tylko poprawki będzie zwiększone.

Oznacza to, że na przykład 3.2.0 jest w pełni kompatybilne do 3.0.0, a 4.0.0 już nie jest binardnie zgodne z 3.0.0. 3.1.0 i 3.1.2 są w pełni zamienne oprócz błędów, które zostały naprawione.

Układ naszych Branch-ów (opisanych poniżej) pozwala nam wspomóc ten proces w dodawaniu drobnych wersji bez zmian i podziału zmuszającego nas do tworzenia głównego wydania. Branch stosuje ten układ do repozytoriów SpongeAPI, SpongeCommon, SpongeForge i SpongeVanilla, ale nie do SpongeDocs.

SpongeAPI, SpongeCommon, SpongeForge i SpongeVanilla

The Bleeding Branch

The core of our repositories is the bleeding branch. Almost all changes will be added to bleeding, including new features, changes, and bugfixes. The version of bleeding will always be the next major release version appended with -SNAPSHOT (eg 6.0.0-SNAPSHOT) to denote that it is not yet a final build and subject to change.

The primary reason for having the bleeding branch is to have a testing ground for changes. Even experienced members of the Sponge team can accidentally cause a build to fail or miss a bug. The bleeding branch will be tested by people in the community that want the very latest, and it means that we can fix bugs that arise far more readily.

Stabilne oddziały

Stabilne elementy repozytoriów reprezentują znacznie bardziej stabilną platformę, na której można wbudować wtyczki i implementacje serwerów. Nie nastąpią uszkodzenia API, jedynie nie łamiących się dodatków. Istnieje część repozytoriów nazwana po każdym większym wydaniu API, która zawiera najnowsze API / implementację dla tej wersji, w tym wszelkie mniejsze wydania lub wydania poprawek.

When the time comes to release a major version, a new stable-x branch will be created from bleeding, where x is the new major version - for example, stable-5. bleeding will be appropriately updated to be the next major release as described above.

Changes that have been in bleeding for a while, which have no known bugs, and that can be applied to a previous major release will be cherry-picked to the relevant stable branch for future release. Changes will be grouped into a new minor version, unless an immediate fix is preferred in which case a bugfix version will be created instead. When a version is released, the API repository will have a tag created pointing to that release’s commit.

Kluczowe elementy repozytoriów

New features or changes should be created in a feature/foo or fix/bar branch. This should be based on the most recent commit to bleeding. The only exception to this is if the changes are incompatible with the breaking changes in bleeding, in which case you should base against the relevant stable-x. You should state in your pull request why your change cannot be included in bleeding - such as fixing a bug in a feature that was removed by Mojang in a later release.

Jeśli wprowadzone zmiany nie zostaną przerwane w poprzedniej wersji, zespół Sponge może również wybrać zmiany w jednej lub kilku gałęziach `` stable``, zakładając, że nie pojawią się żadne problemy po tym, jak zmiana zostanie scalona z `` bleeding``.

SpongeDocs

The SpongeDocs themselves are unversioned following our philosophy that they will never be finished, but instead in a constant flux of ever increasing usability. However they target a specific version of the API, generally the most recent release of SpongeAPI.

Główna gałąź

The core branch for the SpongeDocs is master. Each new commit to master triggers a rebuild of the docs website. Commits to master are generally made to document the most current SpongeAPI release or to fix minor mistakes on the Docs.

Kluczowe elementy repozytoriów

Whenever a new feature is described, older texts are updated or reworded or the documents are restructured, it is done in a feature/foo or fix/bar branch. Those branches will then be reviewed and, once they are deemed complete, may be merged.

Oddział funkcji może zostać scalony tylko z wzorcem, jeśli wprowadzone zmiany / dodatki są poprawne w odniesieniu do ** wydania SpongeAPI, które jest aktualnie adresowane przez SpongeDocs **. Wszelkie oddziały funkcji, które opisują funkcje jeszcze nie zawarte w wydaniu, pozostają niezmienione, dopóki odpowiednia wersja interfejsu API nie zostanie wydana i stanie się nową docelową wersją dla SpongeDocs. Zespół Dokumentów może jednak zbierać dodatki do określonej wersji w jednym oddziale.

Wydanie Branch-y

SpongeDocs uses release/x.y.z branches to publish Docs for older API versions like API 3.1.0. Older API releases are available on their respective branches. Whenever a new API version is released, the Docs Staff will create a new release/x.y.z branch and bump master to the new API version afterwards. A commit to a release branch also triggers a rebuild of the older Docs release, just like on the core branch.