> For the complete documentation index, see [llms.txt](https://docs.kangal.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kangal.dev/tr/referans/release-lifecycle.md).

# Release yaşam döngüsü

Kangal sürümleri, müşterilerin kullanabileceği ürün sürümleridir. Her sürüm için desteklenen yükseltme yolları, uyumluluk değişiklikleri, gerekli hazırlıklar, bilinen sınırlamalar, kullanımdan kaldırmalar ve geri dönüş sınırları konusunda temel kaynak sürüm notlarıdır.

## Sürümleme

Kangal ürün sürümleri `MAJOR.MINOR.PATCH` anlamını kullanır:

* `PATCH`, desteklenen genel sözleşmeleri bilerek değiştirmeden hata veya güvenlik sorunlarını düzeltir.
* `MINOR`, geriye dönük uyumlu yetenekler ekler ve mevcut davranışları kullanımdan kaldırılacak olarak işaretleyebilir.
* `MAJOR`, API, yapılandırma, dağıtım veya veride geriye dönük uyumsuz değişiklikler getirebilir.
* `-rc.1` gibi bir son ek ön sürümü belirtir. Sürüm notları ve destek sözleşmeniz açıkça izin vermedikçe ön sürümü üretimde kullanmayın.

Helm chart'ın ayrı bir sürümü vardır; çünkü chart şablonları, değerleri ve bağımlılıkları uygulama kodundan bağımsız değişebilir. Sürüm notlarında belirtilen Kangal ürün sürümünü ve chart sürümünü birlikte sabitleyin. Paylaşılan veya üretim ortamında `latest` gibi hareketli bir sürüm dağıtmayın.

## Uyumluluk sözleşmesi

* Yeni entegrasyonlar `/api/v1/admin/...` altındaki sürümlü Admin API'ı kullanmalı ve istemcileri dağıtılmış ortamın sunduğu OpenAPI belgesinden üretmelidir.
* Patch ve minor sürümlerde yanıtlara yeni alanlar eklenebilir. İstemciler bilinmeyen alanları yok saymalı ve nesne alanlarının sırasına bağlı olmamalıdır.
* Acil bir güvenlik sorunu daha kısa bir yol gerektirmedikçe desteklenen genel endpoint, alan, yapılandırma anahtarı veya CLI komutu kaldırılmadan önce belgelenmiş bir kullanımdan kaldırma süresi uygulanır.
* API, frontend, worker ve data plane bileşenleri aynı ürün sürümünü çalıştırmalıdır. Karma sürümler yalnızca yükseltme penceresinde veya sürüm notları açıkça belirtiyorsa desteklenir.
* Sunucuyla eşleşen kaynak sürümdeki `kangalctl` aracını kullanın. Ortak `/api/v1` öneki tek başına sürümler arası CLI uyumluluğunu garanti etmez.
* Helm değerleri, yapılandırma paketleri, eklentiler, sağlayıcılar ve veritabanı değişiklikleri yalnızca hedef sürüm notlarında ve geçiş rehberinde belirtildiği ölçüde uyumludur.

## Yükseltmeden önce

1. Kurulu sürümden hedef sürüme kadar bütün sürüm notlarını okuyun. Önerilen yolun desteklendiğini doğrulayın ve gerekli ara sürümleri belirleyin.
2. Mevcut ürün sürümünü, chart sürümünü, etkin bileşenleri, eklentileri, sağlayıcı entegrasyonlarını, data plane sürümlerini ve ortama özgü değerleri kaydedin.
3. Hedef sürüm için geçerli API, CLI, yapılandırma, eklenti, sağlayıcı, işletim sistemi, Python, veritabanı, Redis ve Kubernetes gereksinimlerini inceleyin.
4. Sürüm notlarının istediği yedekleri ve yapılandırma snapshot'larını alın. Geri yükleme kimlik bilgilerinin, saklama süresinin ve yakın tarihli bir geri yükleme testinin mevcut olduğunu doğrulayın.
5. Mevcut Kangal yapılandırmasını dışa aktarın ve korumalı değişiklik kanıtı olarak saklayın; maskelenmiş dışa aktarımların gizli bilgi yedeği olmadığını unutmayın.
6. Yükseltmeyi; üretim ölçeğini, protokollerini, eklentilerini ve dağıtım için önemli entegrasyonlarını temsil eden üretim dışı bir ortamda prova edin.
7. Bakım penceresini, trafik planını, kabul kontrollerini, durdurma koşullarını, geri dönüş sahibini ve geri dönüşün veriyle uyumlu kaldığı son noktayı tanımlayın.

## Sürümü doğrulama

Kurulumdan önce sürüm yapıtlarını onaylı dağıtım kanalından alın ve o sürümle verilen bütünlük doğrulama talimatlarını izleyin. Ürün sürümünün, chart sürümünün, sürüm notlarının ve beklenen bileşen sürümlerinin birbiriyle eşleştiğini doğrulayın.

Prova ve üretim penceresinde en az şunları doğrulayın:

* uygulamadan önce oluşturulan yapılandırma ve değer değişiklikleri;
* sunuluyorsa veritabanı ve yapılandırma geçişi önizlemeleri;
* `/health` ve `/ready` üzerinden iş yükü hazırlığı;
* yönetici girişi, tenant yalıtımı ve gerekli Admin API işlemleri;
* temsilî gateway route'ları, kimlik doğrulama, hız sınırları, eklentiler, upstream'ler, TLS ve kullanılan WebSocket, gRPC, TCP, streaming veya AI yolları;
* arka plan worker'ları, kuyruklar, zamanlanmış işlemler, metrikler, loglar, trace'ler ve alarmlar;
* data plane bağlantısı ve yapılandırma yakınsaması;
* gözlem süresince hata oranı, gecikme, doygunluk ve iş kontrolleri.

Health endpoint'leri tek başına tenant yapılandırmasının veya trafik davranışının doğru olduğunu kanıtlamaz. Route düzeyi ve iş kabul kontrolleri geçmeden yükseltmeyi tamamlanmış saymayın.

## Yükseltme prosedürü

1. Yükseltme boyunca yönetim değişikliklerini dondurun veya uzlaştırın.
2. Yedeklerin, snapshot'ların, kabul kontrollerinin ve geri dönüş karar noktasının güncel olduğunu doğrulayın.
3. Gerekli ön koşul veya veri geçişlerini sürüm notlarında belirtilen sırayla uygulayın.
4. Desteklenen dağıtım yöntemini ve onaylı sürüme sabitlenmiş sürümleri kullanarak yükseltin.
5. Sonraki aşamaya geçmeden veya trafiği artırmadan önce gerekli her bileşenin ve geçiş işinin sağlıklı olmasını bekleyin.
6. Kabul kontrollerini çalıştırın ve sürümü kararlaştırılan süre boyunca gözlemleyin.
7. Veri bütünlüğü riski, tenant sızıntısı, kimlik doğrulama farkı, sürekli SLO gerilemesi, başarısız geçiş veya geri dönüş yeteneğinin kaybı durumunda dağıtımı durdurun.
8. Kurulu sürümleri, doğrulama sonuçlarını, gözlenen etkiyi ve son kabul veya geri dönüş kararını kaydedin.

## Kullanımdan kaldırma ve destek

Sürüm notları ve geçerli müşteri destek politikası; destek durumunu, kullanımdan kaldırma aşamalarını, güvenlik düzeltmesi kullanılabilirliğini ve destek sonu tarihlerini belirtir. Kurulu sürüm veya herhangi bir bağımlılık destek sonuna ulaşmadan yükseltme planlayın.

Bir özellik kullanımdan kaldırılacak olarak işaretlendiğinde bildirim; etkilenen sözleşmeyi, yerine kullanılacak seçeneği, geçiş adımlarını ve planlanan kaldırma sürümünü veya tarihini belirtir. Kullanımdan kaldırma uyarılarını yükseltme işi olarak ele alın; yeni seçeneği sınamak için kaldırılmayı beklemeyin. Destek, sorunun güncel ve desteklenen bir patch sürümünde yeniden üretilmesini isteyebilir.

## Geri dönüş rehberi

İş yükü, yapılandırma ve veri geri dönüşleri ayrı kararlardır. Sürümü değiştirmeden önce hedef sürümün, önceki sürümün okuyamayacağı biçimde saklanan veriyi veya yapılandırmayı değiştirip değiştirmediğini doğrulayın.

* Yalnızca iş yükünü etkileyen gerilemede, ancak sürüm notları veri uyumluluğunu doğruluyorsa daha önce doğrulanmış ürün ve chart sürümlerine dönün.
* Yapılandırma değişikliklerinde kaydedilmiş farkı inceleyin ve onaylı Kangal snapshot'ını veya ileri yönlü düzeltmeyi kullanın.
* Veri değişikliklerinde veritabanı kurtarma prosedürünü, yazma dondurma ve uzlaştırma gereksinimleriyle birlikte izleyin.
* Eski bileşenleri daha yeni ve uyumsuz bir şema ya da kısmen tamamlanmış geçişle çalıştırmayın.

Geri dönüşten sonra health, route, worker, data plane, gözlemlenebilirlik ve iş kontrollerini yineleyin. Başarısız yükseltmenin kanıtlarını koruyun; yeniden denemeden önce nedeni daha yeni bir patch sürümünde veya onaylı destek planında giderin.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.kangal.dev/tr/referans/release-lifecycle.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.