Semantik sürüm oluşturma

Anlamsal sürüm oluşturma

1) SemVer nedir ve neden gereklidir

• MAJOR - kırılma değişiklikleri.
• MINOR, API uyumlu yeni bir özelliktir.
• PATCH - tersinir kusur düzeltmeleri.

Amaç: Sözleşmelerin istikrarı üzerinde anlaşmak ve yükseltmelerin maliyetini azaltmak.

2) Sürüm formatı

• 'BINBAŞI. MINÖR. PATCH [-PRERELEASE] [+ BUILD] '

`1. 4. 7 'kararlı bir sürümdür.
`1. 5. 0-rc. 2 '- yayın öncesi (2 numaralı yayın adayı).
`2. 0. 0 + linux. arm64 '- meta veriler oluşturun (sürüm karşılaştırmasını etkilemez).

1. Önce 'MAJOR', sonra 'MINOR', sonra 'PATCH' karşılaştırılır.

2. Ön sürümler, ilgili kararlı sürümden daha küçüktür: '1. 2. 0-rc. 1 < 1. 2. 0`.

3. Yapı meta verileri ('+...') şu sırayı etkilemez: '1. 2. 0+001 == 1. 2. 0`.

3) Değişimin kırılması olarak kabul edilen şey

• Ortak yöntemlerin/uç noktaların imzasını silme/yeniden adlandırma/değiştirme.
• Giriş/çıkış formatını değiştirin (JSON şeması, türleri).
• Hata sözleşmelerini (kodları/yapıları) değiştirin.
• Yan etkileri/SLA'ları değiştirin (örneğin, katı sınırlar veya yeni gerekli alanlar).

Kesmeme (doğru uygulanırsa): isteğe bağlı alanlar ekleme, enumu yeni değerlerle genişletme (istemci bunları yoksayarsa), yeni uç noktalar, geçerli çağrıları etkilemeyen varsayılanları olan yeni bayraklar.

4) Ön yayınlar ve kanal stratejileri

• Etiketler: 'alfa', 'beta', 'rc'. Örnek: '2. 3. 0-beta. 3`.
• Kanallar: Her gece, alfa, beta, rc, kararlı.
• Politika: Ön sürümler varsayılan üretim düzenekleri için geçişli bağımlılıklar olarak düşmemelidir.

5) Sürüm aralıkları ve kısıtlama doğruluğu

5. 1 Düğüm/npm (varsayılan SemVer)

`^1. 4. 2` ≈ `>=1. 4. 2 <2. 0. 0 '(MINOR/PATCH'e izin verir, MAJOR'ı düzeltir).
`~1. 4. 2` ≈ `>=1. 4. 2 <1. 5. 0 '(MINOR içinde PATCH'e izin verir).
`1. 4. x '1'deki herhangi bir yama. 4.
Tam pin: '1. 4. 2`.

5. 2 Python (PEP 440, pip)

`~=1. 4. 2` ≈ `>=1. 4. 2,==1. 4.`.
`>=1. 4,<2. 0 '- açık sınırlar.

5. 3 Maven/Gradle (Java)

`[1. 4,2. 0) '- kapsayıcı/özel.
Gıda açısından kritik eserler için sıkı tekme önerilir.

5. 4 Go modülleri

Her zaman 'vMAJOR' etiketlerini tamamlayın. MINÖR. PATCH ';' v2 + 'modül soneki'/v2' gerektirir.

Öneri: uygulamalar için - tam pimler (tekrarlanabilir yapılar). Kütüphaneler için - bakım aralıkları (kırılmadan güncellemeleri kolaylaştırın).

6) CHANGELOG и Konvansiyonel Taahhütler

Yapılandırılmış değişiklik günlüğü saydamlığı artırır.

feat(payments): add PIX refund endpoint fix(api): correct 400 → 422 on invalid payload perf(cache): reduce p99 by 20%
refactor(core): extract rule engine docs: update API usage examples chore(deps): bump lodash to 4. 17. 21 feat!: remove legacy webhook v1 (BREAKING CHANGE:...)

Типы: 'Feat', 'fix', 'perf', 'docs', 'refactor', 'angarya' и т. д.
Bir ünlem işareti veya 'BREAKING CHANGE' bloğu MAJOR ilan eder.
CHANGELOG, taahhütlerin tarihinden (botlar tarafından serbest bırakma notları) üretilir.

7) API için sürüm politikası

Genel API'ler: sıkı SemVer; Breaking MAJOR.
HTTP/REST: URL/header ile sürüm oluşturma:'/v1/... ','/v2/...' veya 'Accept: application/vnd. org. hizmet. V2 + json '.
JSON şemaları: küçük uzantılar - yeni isteğe bağlı alanlar; major - sil/değiştir zorunlu.
gRPC/Protobuf: yeni numaralarla yeni alanlar ekleyin; Kullanımdan kaldırmayı silen alan numaralarını yeniden kullanmayın - mevcut olanları kırmayın.

8) Veri ve geçiş planları

Veritabanı geçişleri app @ 1 sürümleriyle senkronize edilir. 8. 0 'schema @ 1 gerektirir. 8. x '.
Şema değişikliklerini kırmak için - aşamalar: genişlet (ekle), taşı, sözleşme (sil). Yalnızca eski sözleşmeyi sildiğinizde MAJOR'a yükseltin.
Geçiş süresince çift yazma/okuma desteği.

9) Monorepos ve mikro hizmetler

Çoklu paket: Her paketin kendi 'MAJOR'u vardır. MINÖR. YAMA '; Yalnızca meta eserler için ortak kök serbest bırakma döngüsü.

• Bağımsız sürümler (Lerna/Changesets) - izolasyonu artırır.
• Kilit adımı - daha kolay iletişim, ancak daha yanlış MAJORS.
• Mikro hizmetler için, sözleşmeleri (OpenAPI/Protobuf) ayrı bir sürümle düzeltin: 'contract @ 2. 1. 0 ', servis onu takip ediyor.

10) CI/CD'deki sürümlerin otomasyonu

• 'mix' - 'PATCH', 'feat' - 'MINOR', '!'/' BREAKING' - 'MAJOR'.

yaml
Pseudo-workflow steps:
- run: npx semantic-release
- run: git tag v$NEW_VERSION && git push --tags
- run: cosign sign ghcr. io/org/app:v$NEW_VERSION

CHANGELOG üretimi, yayın notları yayınlama, GitOps repo'daki bağımlılıkları güncelleme,'ana'nın her zaman son kararlı etikete işaret ettiğini kontrol etme.

11) Yoksunluk politikası

Duyuru: MINOR sürümünde kullanımdan kaldırılan işlevselliği işaretleyin, EOL terimi verin (örn. 90 gün).
Gözlemlenebilirlik: Eski uç noktaların kullanımını kullanıcı/kiracı bağlamında kaydedin.
Silme: aşağıdaki MAJOR'da. Geçiş yolunu belgeleyin.

12) Örnekler ve şablonlar

12. 1 Düzenli SemVer doğrulama ifadesi

regex
^(0    [1-9]\d)\.(0    [1-9]\d)\.(0    [1-9]\d)(?--([0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)))? (?:\+([0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)))?$

12. 2 Karşılaştırma örnekleri

`1. 2. 3` < `1. 10. 0 '(MINOR karşılaştırma).
`2. 0. 0-rc. 1` < `2. 0. 0`.
`1. 2. 3 + yapı. 5` == `1. 2. 3`.

12. 3 Bağımlılık politikası (YAML örneği)

yaml policy:
libraries:
default_range: "^MAJOR. MINOR. PATCH"
pin_security_critical: true services:
pin_exact: true allow_prerelease_in_nonprod: true api_contract:
require_same_minor: true forbid_major_mismatch: true

13) Anti-desenler

Prod'daki'en son'/kayan etiketleri kullanma.
Gerçek arızalar olmadan BÜYÜK geliştirme ("pazarlama sürümleri").
'PATCH' kisvesi altında gizli kırılma değişiklikleri.
Üretim uygulamalarının geçişli bağımlılıklarında ön sürümler.
Nesneyi yeni bir etiket (değiştirilebilir sürümler) olmadan değiştirin.
Tutarsız kod sürümleri ve veritabanı şemaları.

14) Uygulama kontrol listesi (0-45 gün)

0-10 gün

SemVer'i zorunlu bir standart olarak kabul edin, kırma kriterlerini onaylayın.
Konvansiyonel Taahhütler ve 'BREAKING CHANGE' alanına sahip bir PR şablonu ekleyin.

11-25 gün

Anlamsal-serbest bırakma/değiştirme kümelerini bağlayın, CHANGELOG otojenerasyon.
Yapıtların imzalanmasını ve yayınlanmasını vX etiketine karşı yapılandırın. Y.Z '.

26-45 gün

Eski API kullanımı için kullanımdan kaldırma politikasını ve telemetrisini girin.
Sözleşme sürümlerini (OpenAPI/Proto) ve hizmetleri senkronize edin.
Politika düzeyinde'en son've değiştirilebilir etiketleri yasaklayın (OPA/CI düzenlemeleri).

15) Olgunluk metrikleri

Yalnızca SemVer etiketiyle yayınlanan eserlerin %'si.
MINOR sürümleri arasında ortalama geçiş süresi.
Gizli kırılma değişikliklerinden kaynaklanan olay sayısı.
Depolarda Konvansiyonel Taahhütlerin Kapsamı (> %95).
Üründe kayan aralık olmayan bağımlılıkların oranı (> %90).

16) SemVer'e ihtiyaç duyulmadığında

Dış tüketiciler olmadan dahili hızlı prototipler (tarihli sürümler uygundur).
Deneysel özelliklere sahip veri/modeller (dönüştürücü düzeyinde uyumluluk ile daha iyi Model/Şema Sürümleri).
Kararlı bir genel API olmadan içerik paketleri.

17) Sonuç

SemVer, üretici ve tüketici arasındaki bir güven sözleşmesidir. Uyumluluğu neyin bozduğunu açıkça tanımlayın, sürüm tipi tanıma ve eser yayınlamayı otomatikleştirin, şeffaf bir CHANGELOG'u koruyun ve yoksunluk politikalarına uyun. Daha sonra güncellemeler rutin, öngörülebilir ve güvenli hale gelecek ve altyapı ve API'ler işletmeye şok vermeden gelişecektir.