# გამოშვების არხები {#release-channels}

Tuist-ის სერვერი და Kura-ს ქეშირების სერვერი ვრცელდება GHCR-ის სამი გამოსახულების არხის მეშვეობით, რომლებიც განსხვავებულ სტაბილურობის გარანტიებს იძლევა. რეკომენდებული ინსტალაციაა **stable**, რომელიც ყოველ კვირაში ერთხელ ახლდება: ის არ გადადის წინ ყოველ ჯერზე, როდესაც ფუნქცია ერწყმის `main`-ს, ამიტომ განახლება აღარ ნიშნავს არარელევანტური ცვლილებების პაკეტის მიღებას. ადრეული მომხმარებლებს შეუძლიათ გაუშვან თითოეულ კომიტზე აგებული ბილდები **canary**-ზე, ხოლო **release candidate** არხი საშუალებას გაძლევთ წინასწარ შეამოწმოთ მომავალი ხაზი, სანამ ის სტაბილური გახდება.

სერვერი და Kura ერთსა და იმავე კვირეულ ტრენს ემორჩილებიან და ორივე მუშაობს [Tuist CLI-ის გამოშვების გრაფიკთან](/en/cli/release-channels) სინქრონულად.

## არხები {#the-channels}

| არხი | ვერსიის ფორმატი | სიხშირე | ადასტურებს `:latest`-ს? |
| --- | --- | --- | --- |
| Canary | `X.Y.0-canary.N` (მაგ., `1.351.0-canary.5`) | ყოველი კომიტი `main`-ში | არა, მხოლოდ ცხადი არჩევით |
| Release candidate | `X.Y.0-rc.N` (მაგ., `1.351.0-rc.1`) | ჭრა `main`-დან ყოველ ორშაბათს, შემოწმება ~1 კვირა | არა, მხოლოდ ცხადი არჩევით |
| Stable | `X.Y.Z` (მაგ., `1.350.2`, `1.351.0`) | წინ გადატანა ყოველ ორშაბათს წარმატებული შემოწმების შემდეგ | **დიახ** |

Canary და release-candidate ბილდები ქვეყნდება GitHub-ის პრერელიზებად. ნებისმიერი ინსტრუმენტი, რომელიც გამორიცხავს პრერელიზებს `:latest`-ის დროს, გამოტოვებს მათ, ამიტომ მათზე მოხვდებით მხოლოდ მაშინ, როდესაც ცხადად მოითხოვთ.

### Canary {#canary}

ყოველი კომიტი `main`-ში აქვეყნებს canary გამოსახულებას. Canary ყოველთვის წარმოადგენს **შემდეგ გამოუქვეყნებელ მინორულ ვერსიას**: როგორც კი ხაზი გამოშვებისთვის იჭრება, `main` გადადის შემდეგ მინორულ ვერსიაზე (მაგალითად, `1.350.0-canary.42`-დან `1.351.0-canary.1`-მდე). Canary სწორი არხია სატესტო გარემოსთვის, რომელიც ასახავს პროდაქშენს და გაძლევთ რეგრესიებზე ადრეულ სიგნალს, ან საიმისოდ, რომ შეამოწმოთ, თქვენს მიერ შეტყობინებული შესწორება მოსალოდნელად იქცევა, სანამ stable-ში მოხვდება.

```
ghcr.io/tuist/tuist:1.351.0-canary.5
ghcr.io/tuist/kura:0.55.0-canary.5
```

### Release candidate {#release-candidate}

როდესაც მინორული ვერსია მზად არის გამოშვებისთვის, მისი ხაზი იყინება დაცულ `releases/server-<major>.<minor>.x` (ან `releases/kura-<major>.<minor>.x`) ბრენჩზე და ქვეყნდება როგორც `X.Y.0-rc.1`. ხაზი ფუნქციებით გაყინულია; მასზე მხოლოდ კრიტიკული შესწორებები და რეგრესიები გადააქვთ, და ყოველი მიღებული შესწორება ზრდის release candidate-ის ნომერს (`-rc.2`, `-rc.3` და ა.შ.). შემოწმების პერიოდის წარმატებით დასრულების შემდეგ, ხაზი მომდევნო ორშაბათს stable-ში გადადის.

```
ghcr.io/tuist/tuist:1.351.0-rc.1
ghcr.io/tuist/kura:0.55.0-rc.1
```

### Stable {#stable}

Stable რეკომენდებული არხია და ყველა დოკუმენტაცია მასზე მიუთითებს. სტაბილური მინორული ვერსია (`X.Y.0`) ქვეყნდება მხოლოდ მაშინ, როდესაც release candidate წარმატებით შემოწმდება, და ის **არ** გადადის წინ, როდესაც ახალი ფუნქციები ერწყმის `main`-ს. პატჩები (`X.Y.1`, `X.Y.2` და ა.შ.) სტაბილურ ხაზზე შეიცავს მხოლოდ უკან გადატანილ შესწორებებს, არასდროს ახალ ფუნქციებს. `:latest` გადადის მხოლოდ სტაბილურად წინ გადატანისას.

```
ghcr.io/tuist/tuist:1.351.0
ghcr.io/tuist/kura:0.55.0
ghcr.io/tuist/tuist:latest
ghcr.io/tuist/kura:latest
```

## ორშაბათის ტრენი {#the-monday-train}

ყოველ ორშაბათს 06:00 UTC-ზე, სამი კომპონენტის გამოშვების ტრენები სინქრონულად იწყება:

1. **06:00 UTC** — წინ გადატანის ჯობები მუშაობენ. თითოეული გადაჰყავს ყველაზე ახალ release-candidate ხაზს, რომელიც ჯერ არ არის სტაბილური (ჩვეულებრივ, წინა ორშაბათს მოჭრილ ხაზს) და არაფერს აკეთებს, თუ ასეთი არ არის.
2. **ყოველი წინ გადატანის დასრულების შემდეგ** — release-candidate ჯობი ჭრის შემდეგ ხაზს `main`-დან, ამიტომ ახლადმოჭრილი ხაზი არასდროს გადადის წინ იმავე გაშვებაში.

წარუმატებელი წინ გადატანა აჩერებს ჭრას: ირჩევა მხოლოდ უმაღლესი release-candidate ხაზი ბოლო სტაბილურის ზემოთ, ამიტომ შემდეგი ხაზის ჭრა წარუმატებლობის თავზე დატოვებდა იმას, რომელიც არ გამოქვეყნდა. მომდევნო ორშაბათს შეჩერებული ხაზი ავტომატურად თავიდან ცდილობს.

## არხის მიბმა {#pinning-a-channel}

მიუბმეთ სასურველი კონკრეტული ტეგი თქვენს განლაგების მანიფესტში, Helm-ის მნიშვნელობებში ან Docker Compose ფაილში. მაგალითი, Helm ჩარტის გამოყენებით:

```yaml
server:
  image:
    repository: ghcr.io/tuist/tuist
    tag: "1.350.2"          # Pinned to a stable patch
    # tag: "1.351.0-rc.1"   # Or opt into a release candidate to soak it
    # tag: "1.351.0-canary.5" # Or opt into a specific canary build

kuraRuntime:
  image:
    repository: ghcr.io/tuist/kura
    tag: "0.54.0"           # Same three channels apply to Kura
```

`:latest` ორივეზე `ghcr.io/tuist/tuist` და `ghcr.io/tuist/kura` თვალყურს ადევნებს უახლეს სტაბილურს, რომელიც გადადის მხოლოდ ორშაბათის წინ გადატანისას. `:latest`-ის მიბმა გაძლევთ კვირეულ სტაბილურ სიხშირეს ტეგის განახლების გარეშე; კონკრეტული ვერსიის მიბმა გაძლევთ სრულ კონტროლს იმაზე, თუ როდის განაახლებთ.

## რეკომენდებული სტრატეგია {#recommended-strategy}

არხები არსებობს იმისთვის, რომ "უახლესი შესწორებების მიღება" გამოყოთ "უახლესი ფუნქციების მიღებისგან". უსაფრთხო, დაბალი ძალისხმევის ნაგულისხმევი ვარიანტია:

1. **მიუბმეთ პროდაქშენი სტაბილურ მინორულ ხაზს**, მაგალითად `ghcr.io/tuist/tuist:1.351`. ეს ხაზი იღებს მხოლოდ უკან გადატანილ შესწორებებს, არასდროს ახალ ფუნქციებს, ამიტომ ყოველდღიური განახლებები დაბალი რისკისაა. გაზარდეთ მიბმა, როდესაც მზად იქნებით შემდეგი მინორული ვერსიის მიღებისთვის.
2. **გაუშვით სატესტო გარემო canary-ზე ან კონკრეტულ release-candidate ტეგზე.** სატესტო გარემო იჭერს რეგრესიებს, რომლებიც სხვაგვარად მომხმარებლებამდე მიაღწევდნენ, და რაც უფრო ახლოსაა სატესტო გარემო `main`-თან, მით ადრე აღმოაჩენთ მათ. სატესტო გარემო მიმდინარე release-candidate ხაზზე კარგი შუალედური ვარიანტია: ის ამოწმებს ზუსტად იმ ბაიტებს, რომლებიც მომდევნო ორშაბათს სტაბილური გახდება.
3. **მიჰყევით [სერვერის ცვლილებების ჟურნალს](/changelog) იმის გასარკვევად, თუ რა გამოქვეყნდა.** ყოველი სტაბილური წინ გადატანა იქ ანონსდება იმ pull request-ების სიით, რომლებიც შევიდა.

თუ გირჩევნიათ, რომ ახალი ფუნქციები ავტომატურად გადავიდეს პროდაქშენში მათი სტაბილურობის მიღწევისთანავე, დატოვეთ პროდაქშენი `:latest`-ზე. უბრალოდ გაითვალისწინეთ, რომ ტეგი ყოველ ორშაბათს დილით განახლდება, ამიტომ შესაბამისად დაგეგმეთ განთავსების ფანჯარა.

## უკან გადატანა {#backports}

ნებისმიერ დროს აქტიურად მხარდაჭერილია ორი სტაბილური სერვერის (და Kura) ხაზი: მიმდინარე ხაზი იღებს რეგრესიებსა და უსაფრთხოების შესწორებებს უკან გადატანილი pull request-ების სახით, ხოლო წინა ხაზი იღებს მხოლოდ კრიტიკულ და უსაფრთხოების შესწორებებს. ძველ ხაზებზე უკან არ გადაიტანება; გადადით მხარდაჭერილ ხაზზე შესწორებების მიღებისთვის. როდესაც ახალი ხაზი წინ გადაიტანება სტაბილურში, ის ხაზი, რომელიც იყო „მიმდინარე“, ხდება „წინა“, ხოლო ხაზი, რომელიც იყო „წინა“, წყვეტს უკან გადატანების მიღებას.

უკან გადატანები მოთხოვნისას იჭრება როგორც `X.Y.(Z+1)` პატჩ გამოცემები. ისინი არასდროს ცვლიან `:latest`-ს.