From 1c291d9c88666e4fc86eb2c1e56c78f2b1b638f4 Mon Sep 17 00:00:00 2001 From: ospab Date: Sun, 12 Jul 2026 02:12:57 +0300 Subject: [PATCH] =?UTF-8?q?fix(release):=20the=20second=20branch=20is=20'b?= =?UTF-8?q?eta',=20not=20'pre-release'=20=E2=80=94=20was=20never=20checkou?= =?UTF-8?q?table?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit scripts/gha.ps1's -Branch ValidateSet accepted 'pre-release' and would `git checkout pre-release` to promote alpha, but no such branch has ever existed in this repo — only `beta` does (confirmed: `git branch -a`, and the existing 0.4.6-beta/0.4.7-beta release history was cut from `beta`). The very first beta release under the new gha.ps1 versioning scheme would have failed outright on the checkout step. This naming mismatch had spread through the whole release surface: - scripts/gha.ps1: -Branch ValidateSet + all internal checks - .github/workflows/release.yml: a dead branch-name check (harmless only because the workflow currently triggers on tag-push, not branch-push) plus two comments - CONTRIBUTING.md / .ru.md: branch-strategy table documented a `pre-release` branch that doesn't exist - README.md / .ru.md and ostp/src/main.rs: the `ostp update -b ` CLI help text/docs - scripts/install.sh: the channel match the CLI flag feeds into Renamed all of it to `beta` to match the branch that actually exists. Left scripts/gha.ps1:21's "semver pre-release identifier" alone — that's the generic semver spec term, unrelated to the branch name, and got reverted after a blanket replace briefly clobbered it. Note: install.sh's alpha/beta self-update paths still assume a rolling GitHub release tagged literally "alpha"/"beta" exists, which no gha.ps1 release ever publishes (only versioned tags like v0.4.7-beta.3) - that's a separate, real bug, tracked apart from this rename since fixing it needs either a floating tag from gha.ps1 or an API-query rewrite of install.sh. --- .github/workflows/release.yml | 6 +++--- CONTRIBUTING.md | 8 ++++---- CONTRIBUTING.ru.md | 8 ++++---- README.md | 2 +- README.ru.md | 2 +- ostp/src/main.rs | 2 +- scripts/gha.ps1 | 16 ++++++++-------- scripts/install.sh | 6 +++--- 8 files changed, 25 insertions(+), 25 deletions(-) diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index 78b0eed..91a6c02 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -4,7 +4,7 @@ name: CI/CD # `run-name` is evaluated at workflow-start, BEFORE any job runs - it cannot # see resolve-channel's computed tag_name (e.g. "0.4.3-alpha"), only the # `github.*` context. The old "release version ${{ github.ref_name }}" showed -# the bare branch name ("alpha"/"pre-release") for every run, which reads +# the bare branch name ("alpha"/"beta") for every run, which reads # exactly like a literal release tag and caused real confusion - the actual # release tag has been correct (versioned) all along; only this label lied # about it. Spell out "channel" so nobody mistakes one for the other again. @@ -53,7 +53,7 @@ jobs: # Tag shape: # - real "vX.Y.Z" / "vX.Y.Z-beta.N" tag push -> tag used as-is (stable promotion) # - push to `alpha` -> "{version}-alpha" (rolling, same tag every push) - # - push to `pre-release` -> "{version}-beta" (rolling, same tag every push) + # - push to `beta` -> "{version}-beta" (rolling, same tag every push) # - workflow_dispatch -> forced by the `channel` input (alpha|beta only) resolve-channel: name: Resolve release channel @@ -89,7 +89,7 @@ jobs: # channel, then synthesize the rolling tag from Cargo.toml's version. if [ "${{ github.event_name }}" = "workflow_dispatch" ]; then CHANNEL="${{ github.event.inputs.channel }}" - elif [ "${{ github.ref_name }}" = "pre-release" ]; then + elif [ "${{ github.ref_name }}" = "beta" ]; then CHANNEL="beta" else CHANNEL="alpha" diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index cab0db7..72e9566 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -74,10 +74,10 @@ The repository runs three long-lived branches, in increasing order of stability: | Branch | Role | |---|---| | `alpha` | Active development. All feature work and fixes land here first. | -| `pre-release` | Periodically fast-forwarded from `alpha` once it's had some soak time. Ships as the `{version}-beta` release channel. | -| `master` | Fast-forwarded from `pre-release` when it's proven stable. Real, tagged releases (`vX.Y.Z`) are cut from here. | +| `beta` | Periodically fast-forwarded from `alpha` once it's had some soak time. Ships as the `{version}-beta` release channel. | +| `master` | Fast-forwarded from `beta` when it's proven stable. Real, tagged releases (`vX.Y.Z`) are cut from here. | -`pre-release` and `master` are **never** committed to directly - they only ever move forward by fast-forwarding from the branch below them. This means promotion is always a plain `git merge` with zero conflicts by construction: don't `git merge`/rebase feature work directly onto `pre-release` or `master`. +`beta` and `master` are **never** committed to directly - they only ever move forward by fast-forwarding from the branch below them. This means promotion is always a plain `git merge` with zero conflicts by construction: don't `git merge`/rebase feature work directly onto `beta` or `master`. **Contributor PRs target `alpha`**, not `master`. @@ -148,7 +148,7 @@ Multiple unrelated changes belong in separate commits, not one bundled commit - ```bash git push origin feat/your-feature-name ``` -2. Open a Pull Request (PR) targeting the `alpha` branch (see [Branch Strategy](#branch-strategy) - `master` only receives fast-forwards from `pre-release`, never direct PRs). +2. Open a Pull Request (PR) targeting the `alpha` branch (see [Branch Strategy](#branch-strategy) - `master` only receives fast-forwards from `beta`, never direct PRs). 3. In your PR description, explain the rationale behind your changes, what was fixed/added, and how it was tested. 4. Verify that GitHub Actions CI runs successfully on your PR. diff --git a/CONTRIBUTING.ru.md b/CONTRIBUTING.ru.md index 0108141..4d9707e 100644 --- a/CONTRIBUTING.ru.md +++ b/CONTRIBUTING.ru.md @@ -74,10 +74,10 @@ | Ветка | Роль | |---|---| | `alpha` | Активная разработка. Вся новая работа и фиксы попадают сюда первыми. | -| `pre-release` | Периодически перематывается вперёд (fast-forward) от `alpha`, когда та немного «отлежалась». Собирается в канал релиза `{версия}-beta`. | -| `master` | Перематывается вперёд от `pre-release`, когда та доказала стабильность. Настоящие тегированные релизы (`vX.Y.Z`) режутся отсюда. | +| `beta` | Периодически перематывается вперёд (fast-forward) от `alpha`, когда та немного «отлежалась». Собирается в канал релиза `{версия}-beta`. | +| `master` | Перематывается вперёд от `beta`, когда та доказала стабильность. Настоящие тегированные релизы (`vX.Y.Z`) режутся отсюда. | -В `pre-release` и `master` **никогда** не коммитят напрямую - они только перематываются вперёд от ветки уровнем ниже. Это значит, что промоушен - всегда обычный `git merge` без единого конфликта по построению: не мержите/не ребейзьте свою фичу прямо в `pre-release` или `master`. +В `beta` и `master` **никогда** не коммитят напрямую - они только перематываются вперёд от ветки уровнем ниже. Это значит, что промоушен - всегда обычный `git merge` без единого конфликта по построению: не мержите/не ребейзьте свою фичу прямо в `beta` или `master`. **PR от контрибьюторов нацелены на `alpha`**, не на `master`. @@ -149,7 +149,7 @@ obfuscation_key/psk), чтобы он был индивидуальным для ```bash git push origin feat/имя-вашей-фичи ``` -2. Создайте Pull Request (PR) в ветку `alpha` основного репозитория (см. [Стратегия веток](#стратегия-веток) - `master` получает только fast-forward от `pre-release`, PR туда не принимаются напрямую). +2. Создайте Pull Request (PR) в ветку `alpha` основного репозитория (см. [Стратегия веток](#стратегия-веток) - `master` получает только fast-forward от `beta`, PR туда не принимаются напрямую). 3. Подробно опишите внесенные изменения: какая проблема решается, как проводилось тестирование и на каких платформах проверялась сборка. 4. Убедитесь, что автоматическое тестирование (GitHub Actions CI) завершилось успешно. diff --git a/README.md b/README.md index 078d91d..7505188 100644 --- a/README.md +++ b/README.md @@ -192,7 +192,7 @@ Commands: links Print client share links from the server config import Import a share link into the config file update Update OSTP to the latest release - -b, --branch Release channel: stable, pre-release, alpha (default: stable) + -b, --branch Release channel: stable, beta, alpha (default: stable) -v, --version Update to an exact version instead of the channel's latest migrate Force-migrate the configuration file to the current format proxy-env Print shell export commands for the local SOCKS proxy diff --git a/README.ru.md b/README.ru.md index 16bb4cd..c14b924 100644 --- a/README.ru.md +++ b/README.ru.md @@ -181,7 +181,7 @@ ostp [--config ] [КОМАНДА] links Вывести client-share-ссылки из серверного конфига import Импортировать share-ссылку в конфиг update Обновить OSTP до актуального релиза - -b, --branch Канал релиза: stable, pre-release, alpha (по умолчанию stable) + -b, --branch Канал релиза: stable, beta, alpha (по умолчанию stable) -v, --version Обновиться на точную версию вместо последней в канале migrate Принудительно мигрировать конфиг к текущему формату proxy-env Вывести shell-команды для локального SOCKS-прокси diff --git a/ostp/src/main.rs b/ostp/src/main.rs index 3260294..852378e 100644 --- a/ostp/src/main.rs +++ b/ostp/src/main.rs @@ -54,7 +54,7 @@ enum Commands { Uninstall, /// Update OSTP: re-run the install script to fetch and install the latest version Update { - /// Release branch to update from (stable, pre-release, alpha) + /// Release branch to update from (stable, beta, alpha) #[arg(short = 'b', long, default_value = "stable")] branch: String, /// Exact release version to update to (e.g. 0.4.1 or 0.4.1-beta.3), diff --git a/scripts/gha.ps1 b/scripts/gha.ps1 index ee82c05..faf331c 100644 --- a/scripts/gha.ps1 +++ b/scripts/gha.ps1 @@ -24,7 +24,7 @@ Promoting to beta/master first fast-forwards that branch to `alpha` (--ff-only — this always succeeds cleanly as long as nobody ever commits - directly to pre-release/master, per CONTRIBUTING.md's branch strategy), so + directly to beta/master, per CONTRIBUTING.md's branch strategy), so a release always ships alpha's latest, not a stale branch. Switching to a channel for the first time in a cycle resets THAT channel's iteration counter to 1 (a fresh promotion starts its own count; it doesn't inherit @@ -50,7 +50,7 @@ parameter is the only thing that fixes it. Do not rename this back. .PARAMETER Branch - Which branch/channel to release from: master, pre-release (beta), or alpha. + Which branch/channel to release from: master, beta, or alpha. Defaults to whatever was used last time (see .release-state.json). .EXAMPLE @@ -63,8 +63,8 @@ ships v0.4.2-alpha.1. .EXAMPLE - .\scripts\gha.ps1 -Branch pre-release - Promotes alpha -> pre-release (beta channel), resets beta_iteration to 1 + .\scripts\gha.ps1 -Branch beta + Promotes alpha -> beta (beta channel), resets beta_iteration to 1 (or bumps it if already mid-beta), ships v{target}-beta.{N}. .EXAMPLE @@ -74,7 +74,7 @@ [CmdletBinding()] param( [string]$NewVersion, - [ValidateSet('master', 'pre-release', 'alpha')] + [ValidateSet('master', 'beta', 'alpha')] [string]$Branch ) @@ -133,11 +133,11 @@ if ($IsNewTarget) { # Entering a channel that wasn't active last run (a promotion) starts # THAT channel's count fresh — it doesn't inherit alpha's iteration number. $BranchChanged = ($ResolvedBranch -ne $PrevBranch) - if ($BranchChanged -and $ResolvedBranch -eq "pre-release") { $BetaIter = 0 } + if ($BranchChanged -and $ResolvedBranch -eq "beta") { $BetaIter = 0 } if ($BranchChanged -and $ResolvedBranch -eq "alpha") { $AlphaIter = 0 } } -$Channel = switch ($ResolvedBranch) { "alpha" { "alpha" }; "pre-release" { "beta" }; "master" { "stable" } } +$Channel = switch ($ResolvedBranch) { "alpha" { "alpha" }; "beta" { "beta" }; "master" { "stable" } } if ($Channel -eq "alpha") { $AlphaIter++ } elseif ($Channel -eq "beta") { $BetaIter++ } @@ -230,7 +230,7 @@ git commit -m $commitMsg | Out-Null # -- Push. release.yml triggers ONLY on "v*" tag pushes (no branch trigger), - # -- so the tag push is what actually starts the build; the branch push is - -# -- just so the promotion chain (alpha -> pre-release -> master) itself - +# -- just so the promotion chain (alpha -> beta -> master) itself - # -- keeps moving forward for the next --ff-only. - Write-Step "Tagging $Tag and pushing $ResolvedBranch + tag" git tag $Tag diff --git a/scripts/install.sh b/scripts/install.sh index 33c89ee..0ee5276 100644 --- a/scripts/install.sh +++ b/scripts/install.sh @@ -118,9 +118,9 @@ else if [ "$TARGET_BRANCH" == "alpha" ]; then echo "Fetching alpha release..." LATEST_RELEASE="alpha" - elif [ "$TARGET_BRANCH" == "pre-release" ]; then - echo "Fetching pre-release..." - LATEST_RELEASE="pre-release" + elif [ "$TARGET_BRANCH" == "beta" ]; then + echo "Fetching beta release..." + LATEST_RELEASE="beta" else echo "Fetching latest stable release..." LATEST_RELEASE=$(curl -s "https://api.github.com/repos/${GITHUB_REPO}/releases/latest" | grep '"tag_name":' | sed -E 's/.*"([^"]+)".*/\1/')