Repository Branch Layout

The layout of our branches is designed to assist semantic versioning by allowing us to make minor releases without a breaking change forcing us to make it a major release. This branch layout applies to SpongeAPI, SpongeCommon, SpongeForge, and SpongeVanilla repositories but not to the SpongeDocs.

SpongeAPI, SpongeCommon, SpongeForge dan SpongeVanilla

Cabang Pendarahan

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 (e.g. 7.0.0-SNAPSHOT) to denote that it is not yet a final build and subject to change.

Alasan utama untuk memiliki cabang `` perdarahan` adalah memiliki tempat uji coba untuk perubahan. Bahkan anggota tim Sponge yang berpengalaman dapat secara tidak sengaja menyebabkan kegagalan atau kehilangan bug. Cabang `` bleeding`` akan diuji oleh orang-orang di masyarakat yang menginginkan yang terbaru, dan itu berarti kita dapat memperbaiki bug yang muncul dengan lebih mudah.

Cabang yang Stabil

Cabang stabil mewakili platform yang jauh lebih stabil yang dapat digunakan plugin dan implementasi server. Tidak akan ada kerusakan API, hanya penambahan yang tidak melanggar. Ada cabang yang dinamai setiap rilis API utama, yang berisi API / implementasi terbaru untuk rilis tersebut termasuk rilis minor atau patch lainnya.

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-7. bleeding will be appropriately updated to be the next major release as described above.

Perubahan yang terjadi pada `` pendarahan`` untuk sementara, yang tidak memiliki bug yang diketahui, dan yang dapat diterapkan pada pelepasan mayor sebelumnya akan dipilih secara ceri ke yang relevan. cabang `` stabil` untuk rilis selanjutnya. Perubahan akan dikelompokkan ke dalam versi minor yang baru, kecuali jika perbaikan segera lebih disukai dimana versi bugfix akan dibuat. ketika sebuah versi dilepaskan, api repositori akan memiliki tag dibuat menunjuk bahwa rilis ini melakukan.

Fitur cabang

Fitur baru atau perubahan harus dibuat dalam `` fitur / foo`` atau `` memperbaiki / bar`` cabang. ini harus didasarkan pada yang terbaru berkomitmen untuk `` bleeding``. satu-satunya pengecualian ini adalah jika perubahan yang tidak kompatibel dengan melanggar perubahan `` bleeding``, dalam hal ini Anda harus dasar terhadap relevan `` stabil-x``. Negara Anda harus tarik permintaan mengapa Anda mengubah tidak bisa dimasukkan di `` bleeding`` - seperti memperbaiki bug dalam fitur yang telah dihapus oleh mojang kemudian di rilis.

Jika perubahan yang dilakukan tidak melanggar untuk rilis sebelumnya, tim Sponge juga dapat memilih perubahan pada satu atau lebih cabang `` stabil` dengan anggapan bahwa tidak ada masalah yang timbul setelah perubahan tersebut digabungkan menjadi `` pendarahan``.

Dokumen Sepon

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.

Cabang Inti

Cabang inti untuk SpongeDocs adalah `` stable``. Setiap komit baru untuk `` stabil` memicu pembangunan kembali situs web docs <https://docs.spongepowered.org/> _. Berkomitmen untuk ` stabil`` umumnya dibuat untuk mendokumentasikan pelepasan SpongeAPI terbaru atau memperbaiki kesalahan kecil pada Dokumen.

Fitur cabang

Setiap kali fitur baru dijelaskan, teks yang lebih lama akan diperbarui atau dicetak ulang atau dokumen direstrukturisasi, dilakukan di cabang `` feature / foo`` atau `` fix / bar``. Cabang-cabang tersebut kemudian akan ditinjau dan, setelah dianggap selesai, maka dapat digabungkan.

A feature branch may only be merged into master if the changes / additions made in it are correct regarding the SpongeAPI release currently targeted by the SpongeDocs. Any feature branches that describe features not yet included in a release stay unmerged until the corresponding API version is released and becomes the new targeted version for the SpongeDocs. However, the Docs team might collect additions for a specific version on a single branch.

Lepaskan Cabang

SpongeDocs menggunakan cabang `` release / x.y.z`` untuk menerbitkan Documents untuk versi API lama seperti API `` 3.1.0``. Rilis API yang lebih lama tersedia di cabang masing-masing. Setiap kali versi API baru dilepaskan, Staf Dokumen akan membuat cabang `` release / x.y.z`` baru dan benjolan master ke versi API yang baru sesudahnya. Sebuah komit ke cabang `` release`` juga memicu penataan kembali rilis Documents yang lebih tua, seperti di cabang inti.