Sürüm oluşturma ve Depo dallandırma Düzeni

With the release for beta we’ve moved SpongeAPI versioning to semantic versioning (see https://semver.org/). This change means that every time that we make a release we have to increment the version according to the rules of SemVer.

SemVer

SemVer, `` X`` bir * major * versiyonu, `` Y`` bir * minor * ve Z * patch * versiyonu olan` X.Y.Z` düzenini kullanır. Geriye dönük uyumlu olmayan değişiklikler içeren bir sürüm, bir önceki sürümün bir * büyük * sürümü olmalıdır. Yine de geriye dönük olarak uyumlu yeni özellikler varsa, yeni sürüm bir önceki sürümü öncesinde bir * küçük * sürüm olacak ve sürüm hata düzeltmeleri içeriyorsa yalnızca * yama * sürümü artırılacaktır.

Bunun anlamı, örneğin 3.2.0 tamamen 3.0.0 ile uyumlu, 4.0.0 da 3.0.0 ile ikili uyumlu değildir. 3.1.0 ve 3.1.2, giderilen hataların yanı sıra tamamen değiştirilebilir.

The layout of our branches (described below) is designed to assist this process 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 ve SpongeVanilla

The bleeding dallanması

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

“Bleeding” dalının bulunmasının başlıca nedeni, değişiklikler için bir test yerinin bulunmasıdır. Sponge takımının deneyimli üyeleri bile kazara bir yapının başarısız olmasına veya bir hatayı sebep olmasına neden olabilir. “Bleeding” dalı, topluluktaki insanlar tarafından test edilecek ve bu, hataları çok daha kolay bir şekilde giderebileceğimiz anlamına geliyor.

Stabil dallanmalar

Durağan dallar, eklentilerin ve sunucu uygulamalarının üzerine kurulabilecek çok daha istikrarlı bir platformu temsil eder. API için kırılma olmayacak, sadece kırılmayı önleyen eklemeler olmayacaktır. Her büyük API sürümünden sonra, küçük veya düzeltme eki sürümleri de dahil olmak üzere, bu sürümler için en yeni API / uygulamanın bulunduğu bir dal var.

Büyük bir sürümü yayımlamaya geldiğinde Bleeding'''den yeni bir ``stable-x dalı oluşturulur; burada x yeni ana sürümdür - örneğin stable-5''. “bleeding”, yukarıda tarif edildiği gibi bir sonraki ana sürüm olarak uygun şekilde güncellenecektir.

Bir süre için “kanama(bleeding)” geçiren, bilinen böcekleri olmayan ve bir önceki büyük yayına uygulanabilen değişiklikler, gelecekteki sürüm için “kararlı” dalla kiraz olarak seçilecek. Bunun yerine bir hata düzeltme sürümünün oluşturulacağı derhal bir düzeltme yapılmadığı sürece değişiklikler yeni bir alt sürüm olarak gruplandırılacaktır. Bir sürüm yayınlandığında, API deposunun bu sürümün taahhütüne işaret eden bir etiketi olacaktır.

Gelecek dallanmalar

Yeni özellikler veya değişiklikler feature/foo veya fix/bar dalında oluşturulmalıdır. Bu, en son “bleeding” taahhüdüne dayanmalıdır. Bunun tek istisnası, değişiklikler “bleeding” ‘de ki kırılma değişiklikleri ile uyuşmuyorsa, bu durumda ilgili ``stable-x “e karşı dayanması gerekir. Değişikliğinizin “bleeding“‘e neden dahil edilemediğini (örneğin, daha sonraki bir sürümde Mojang tarafından kaldırılan bir özelliğe hatayı düzeltmek gibi) çekme isteğinizi belirtmelisiniz.

Yapılan değişiklikler bir önceki sürüm için kırılmıyorsa, Sponge takımı değişikliğin “bleeding” ile birleştirilmesinden sonra herhangi bir sorun çıkmadığını varsayarak bir veya daha fazla “stable” dalda değişiklikleri alabilir.

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.

Çekirdek dal

SpongeDocs’un temel dalı “stable” dır. Her yeni “stable” taahhüt docs web sitesinin yeniden oluşturulmasını tetikler. “Sabit” durumdaki taahhütler genellikle en yeni SpongeAPI sürümünü belgelemek veya Belgelerdeki küçük hataları düzeltmek için yapılır.

Gelecek dallanmalar

Yeni bir özellik tarif edildiğinde, eski metinler güncellenir veya yeniden derlenir veya belgeler yeniden yapılandırılır, bir feature/foo veya fix/bar dalında yapılır. Bu dallar daha sonra gözden geçirilecek ve tamamlandıklarında birleştirileceklerdir.

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.

release branch example

Dalları yayımlama

SpongeDocs, API’leri “3.1.0” gibi daha eski API sürümleri ve Dokümanları yayımlamak için “release/x.y.z” dallarını kullanır. Eski API sürümleri, ilgili dalında bulunur. Yeni bir API sürümü her yayımlandığında, Docs Çalışanları daha sonra yeni bir API sürümüne yeni bir release/x.y.z şube ve takas masterı oluşturacaktır. Release dalına bir taahhüt de tıpkı ana daldaki gibi daha eski Docs sürümünün yeniden oluşturulmasını tetikler.