WealthLedger/main
5
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

chore: release current develop state by the linear git model #30

New Issue
Closed
opened 2026-10-12 23:17:26 +03:00 by codex-bot · 3 comments
codex-bot commented 2026-10-12 23:17:26 +03:00
Owner
Copy Link
Copy Source

Goal

Выпустить текущее принятое состояние develop во всех пяти независимо релизимых репозиториях WealthLedger по линейной модели из #34 и обновить deployment bundle на полученные теги образов frontend и backend.

Контекст

Предыдущая редакция этой Issue описывала релиз через back-merge main → develop. Этот шаг отменён в #34 (коммит 0bdc409): merge-коммиты запрещены (allow_merge_commits=false), main обновляется только fast-forward из develop. Семь PR, созданных под старую модель, закрыты как устаревшие — каждый с подтверждением, что он не несёт изменений, отсутствующих в develop (frontend#87, #88, backend#107, #108, #80, docs#39, specs#36).

Предыдущий цикл выпущен: теги v0.2.2 / v1.1.0 / v2.1.0 / v0.1.4 / v0.1.4 на месте. С тех пор develop снова ушёл вперёд, поэтому требуется новый цикл.

Исходное состояние

Снято на 2026-10-17 после очистки веток:

repo main тег develop ahead типы коммитов
main 3027fd5 v0.2.2 d07fbfa 3 docs, chore
frontend c7d8d2c v1.1.0 eefdde2 19 6×fix, feat, 4×test, 2×ci, refactor, build, chore
backend 3d50db7 v2.1.0 4f485ab 23 6×fix, feat, 5×test, 5×chore, 2×refactor, 2×perf, ci
docs add9e5f v0.1.4 11f819e 11 5×docs, ci, chore
specs aae23d8 v0.1.4 06d08e2 14 6×spec, 2×chore, ci

Инвариант origin/main — предок origin/develop выполняется во всех пяти:

git merge-base --is-ancestor origin/main origin/develop && echo ok

Версию выбирает release-it по принятым Conventional Commits; значения выше приведены как контекст, а не как решение. feat в frontend и backend указывает на minor, остальные — на patch.

Процедура

Для каждого репозитория по процессу релиза:

  1. git fetch origin --tags, проверить инвариант.
  2. Ветка release/X.Y.Z от проверенного develop, npm ci.
  3. Локальные required проверки репозитория.
  4. npm run release:preview, затем npm run release:prepare.
  5. PR release/X.Y.Z → develop, title chore(release): X.Y.Z, merge ff-only.
  6. PR develop → main, тот же title, merge ff-only.
  7. git tag -a vX.Y.Z <main-sha> -m "Release X.Y.Z", git push origin refs/tags/vX.Y.Z.

Шага back-merge main → develop нет. Пока открыт релизный PR, develop не двигают.

Acceptance Criteria

  • В каждом из пяти репозиториев подготовлен кандидат от текущего develop; версия выбрана release-it по принятым Conventional Commits.
  • Каждый кандидат прошёл свои required локальные проверки и required CI, затем слит в main fast-forward.
  • На каждом релизном коммите main ровно один аннотированный неизменяемый тег vX.Y.Z.
  • Инвариант origin/main — предок origin/develop сохранён после релиза во всех пяти; отдельного sync-PR не создаётся.
  • Merge-коммитов в main и develop не добавлено.
  • deploy обновлён через свой review flow на выпущенные теги образов frontend и backend.
  • Запись релиза содержит SHA кандидатов, теги, результаты проверок и ограничения.

Exclusions

  • Открытые PR, не слитые в develop, включая Renovate (frontend#52, backend#51), в релиз не входят.
  • Незакрытые Issues кампании audit/2026-10-11 и прочий backlog в scope не входят.
  • Публикация образов в Nexus блокирована отдельно (#15, frontend#21, backend#25): если блокировка сохраняется, это фиксируется как ограничение релиза, а не обходится.

Verification

for d in . frontend backend docs specs; do
  git -C "$d" fetch -q origin --tags
  git -C "$d" merge-base --is-ancestor origin/main origin/develop && echo "$d ok"
  git -C "$d" tag --points-at origin/main
done

Ограничение: зелёные локальные gates и порядок публикации не доказывают совместимость развёрнутых версий — она согласуется отдельно через публичные контракты.

## Goal Выпустить текущее принятое состояние `develop` во всех пяти независимо релизимых репозиториях WealthLedger по линейной модели из `#34` и обновить deployment bundle на полученные теги образов frontend и backend. ## Контекст Предыдущая редакция этой Issue описывала релиз через back-merge `main → develop`. Этот шаг отменён в `#34` (коммит `0bdc409`): merge-коммиты запрещены (`allow_merge_commits=false`), `main` обновляется только fast-forward из `develop`. Семь PR, созданных под старую модель, закрыты как устаревшие — каждый с подтверждением, что он не несёт изменений, отсутствующих в `develop` (`frontend#87`, `#88`, `backend#107`, `#108`, `#80`, `docs#39`, `specs#36`). Предыдущий цикл выпущен: теги `v0.2.2` / `v1.1.0` / `v2.1.0` / `v0.1.4` / `v0.1.4` на месте. С тех пор `develop` снова ушёл вперёд, поэтому требуется новый цикл. ## Исходное состояние Снято на 2026-10-17 после очистки веток: | repo | `main` | тег | `develop` | ahead | типы коммитов | | --- | --- | --- | --- | --- | --- | | `main` | `3027fd5` | `v0.2.2` | `d07fbfa` | 3 | `docs`, `chore` | | `frontend` | `c7d8d2c` | `v1.1.0` | `eefdde2` | 19 | 6×`fix`, `feat`, 4×`test`, 2×`ci`, `refactor`, `build`, `chore` | | `backend` | `3d50db7` | `v2.1.0` | `4f485ab` | 23 | 6×`fix`, `feat`, 5×`test`, 5×`chore`, 2×`refactor`, 2×`perf`, `ci` | | `docs` | `add9e5f` | `v0.1.4` | `11f819e` | 11 | 5×`docs`, `ci`, `chore` | | `specs` | `aae23d8` | `v0.1.4` | `06d08e2` | 14 | 6×`spec`, 2×`chore`, `ci` | Инвариант `origin/main` — предок `origin/develop` выполняется во всех пяти: ```bash git merge-base --is-ancestor origin/main origin/develop && echo ok ``` Версию выбирает `release-it` по принятым Conventional Commits; значения выше приведены как контекст, а не как решение. `feat` в `frontend` и `backend` указывает на minor, остальные — на patch. ## Процедура Для каждого репозитория по [процессу релиза](../README.md#релизы-и-ветки): 1. `git fetch origin --tags`, проверить инвариант. 2. Ветка `release/X.Y.Z` от проверенного `develop`, `npm ci`. 3. Локальные required проверки репозитория. 4. `npm run release:preview`, затем `npm run release:prepare`. 5. PR `release/X.Y.Z → develop`, title `chore(release): X.Y.Z`, merge ff-only. 6. PR `develop → main`, тот же title, merge ff-only. 7. `git tag -a vX.Y.Z <main-sha> -m "Release X.Y.Z"`, `git push origin refs/tags/vX.Y.Z`. Шага back-merge `main → develop` нет. Пока открыт релизный PR, `develop` не двигают. ## Acceptance Criteria - [ ] В каждом из пяти репозиториев подготовлен кандидат от текущего `develop`; версия выбрана `release-it` по принятым Conventional Commits. - [ ] Каждый кандидат прошёл свои required локальные проверки и required CI, затем слит в `main` **fast-forward**. - [ ] На каждом релизном коммите `main` ровно один аннотированный неизменяемый тег `vX.Y.Z`. - [ ] Инвариант `origin/main` — предок `origin/develop` сохранён после релиза во всех пяти; отдельного sync-PR не создаётся. - [ ] Merge-коммитов в `main` и `develop` не добавлено. - [ ] `deploy` обновлён через свой review flow на выпущенные теги образов frontend и backend. - [ ] Запись релиза содержит SHA кандидатов, теги, результаты проверок и ограничения. ## Exclusions - Открытые PR, не слитые в `develop`, включая Renovate (`frontend#52`, `backend#51`), в релиз не входят. - Незакрытые Issues кампании `audit/2026-10-11` и прочий backlog в scope не входят. - Публикация образов в Nexus блокирована отдельно (`#15`, `frontend#21`, `backend#25`): если блокировка сохраняется, это фиксируется как ограничение релиза, а не обходится. ## Verification ```bash for d in . frontend backend docs specs; do git -C "$d" fetch -q origin --tags git -C "$d" merge-base --is-ancestor origin/main origin/develop && echo "$d ok" git -C "$d" tag --points-at origin/main done ``` Ограничение: зелёные локальные gates и порядок публикации не доказывают совместимость развёрнутых версий — она согласуется отдельно через публичные контракты.
codex-bot added the Kind/Process label 2026-10-12 23:17:26 +03:00
codex-bot commented 2026-10-17 20:02:22 +03:00
Author
Owner
Copy Link
Copy Source

Приведение к линейной модели

Acceptance Criteria этой Issue написаны под старую release-модель и содержат пункт, отменённый в #34:

Each release commit is returned to develop through a non-squashed, non-rebased main -> develop PR.

Back-merge main → develop больше не существует, merge-коммиты запрещены (allow_merge_commits=false). Все семь PR, созданных под этот пункт, закрыты как устаревшие с подтверждением, что они не несут изменений, отсутствующих в develop:

repo PR head → base
frontend #87 develop → chore/30-sync-release
frontend #88 main → chore/30-sync-from-develop
backend #107 develop → chore/30-sync-release
backend #108 main → chore/30-sync-from-develop
backend #80 main → develop
docs #39 main → develop
specs #36 main → develop

Проверка по каждому: все их head-ref — предки origin/develop, git rev-list --count origin/develop..origin/main = 0 во всех пяти репозиториях.

Временные ветки chore/30-sync-release и chore/30-sync-from-develop удалены.

Фактическое состояние релизов

Релизный цикл по этой Issue выполнен, теги на месте:

repo          main      tag      develop   develop ahead of main
WealthLedger  3027fd5   v0.2.2   d07fbfa   3
frontend      c7d8d2c   v1.1.0   eefdde2   19
backend       3d50db7   v2.1.0   4f485ab   23
docs          add9e5f   v0.1.4   11f819e   11
specs         aae23d8   v0.1.4   06d08e2   14

Инвариант origin/main — предок origin/develop выполняется во всех пяти.

С момента релиза в develop накопились новые изменения, поэтому «выпустить текущее состояние develop» снова актуально — но уже как следующий релизный цикл по линейной модели (release/X.Y.Z → develop → main --ff-only → tag), без шага back-merge.

Issue оставлена открытой: решение о том, закрыть её как выполненную для цикла v0.2.2/v1.1.0/v2.1.0/v0.1.4 или переиспользовать для следующего релиза, за владельцем. AC в текущем виде недостижимы, так как требуют отменённого шага.

## Приведение к линейной модели Acceptance Criteria этой Issue написаны под старую release-модель и содержат пункт, отменённый в `#34`: > Each release commit is returned to `develop` through a non-squashed, non-rebased `main -> develop` PR. Back-merge `main → develop` больше не существует, merge-коммиты запрещены (`allow_merge_commits=false`). Все семь PR, созданных под этот пункт, закрыты как устаревшие с подтверждением, что они не несут изменений, отсутствующих в `develop`: | repo | PR | head → base | | --- | --- | --- | | frontend | #87 | develop → chore/30-sync-release | | frontend | #88 | main → chore/30-sync-from-develop | | backend | #107 | develop → chore/30-sync-release | | backend | #108 | main → chore/30-sync-from-develop | | backend | #80 | main → develop | | docs | #39 | main → develop | | specs | #36 | main → develop | Проверка по каждому: все их head-ref — предки `origin/develop`, `git rev-list --count origin/develop..origin/main` = 0 во всех пяти репозиториях. Временные ветки `chore/30-sync-release` и `chore/30-sync-from-develop` удалены. ## Фактическое состояние релизов Релизный цикл по этой Issue выполнен, теги на месте: ``` repo main tag develop develop ahead of main WealthLedger 3027fd5 v0.2.2 d07fbfa 3 frontend c7d8d2c v1.1.0 eefdde2 19 backend 3d50db7 v2.1.0 4f485ab 23 docs add9e5f v0.1.4 11f819e 11 specs aae23d8 v0.1.4 06d08e2 14 ``` Инвариант `origin/main` — предок `origin/develop` выполняется во всех пяти. С момента релиза в `develop` накопились новые изменения, поэтому «выпустить текущее состояние `develop`» снова актуально — но уже как следующий релизный цикл по линейной модели (`release/X.Y.Z → develop → main --ff-only → tag`), без шага back-merge. Issue оставлена открытой: решение о том, закрыть её как выполненную для цикла `v0.2.2/v1.1.0/v2.1.0/v0.1.4` или переиспользовать для следующего релиза, за владельцем. AC в текущем виде недостижимы, так как требуют отменённого шага.
codex-bot changed title from chore: release all current develop changes to chore: release current develop state by the linear git model 2026-10-17 20:53:22 +03:00
codex-bot commented 2026-10-17 20:53:43 +03:00
Author
Owner
Copy Link
Copy Source

Issue переоформлена под следующий релизный цикл по линейной модели.

Что изменилось в постановке

Было (старая модель) Стало
release/X.Y.Z от develop → ff в main → back-merge PR main → develop release/X.Y.Z → develop (ff) → develop → main (ff) → тег
AC: «Each release commit is returned to develop through a non-squashed, non-rebased main -> develop PR» AC: «Инвариант origin/main — предок origin/develop сохранён; отдельного sync-PR не создаётся»
Голые ожидания без исходного состояния Таблица main/тег/develop/ahead/типы коммитов на 2026-10-17

Старая формулировка была недостижима: требуемый шаг отменён в #34, а merge-коммиты запрещены настройками всех пяти репозиториев.

Заголовок изменён с «release all current develop changes» на «release current develop state by the linear git model» — прежний не отличал этот цикл от предыдущего, уже выпущенного.

Почему Issue не закрыта и не заменена новой

Предыдущий цикл (v0.2.2/v1.1.0/v2.1.0/v0.1.4) выпущен и его теги на месте — это зафиксировано в разделе «Контекст». Но результат Issue в title — «выпустить текущее состояние develop» — остаётся недостигнутым: develop снова впереди на 3/19/23/11/14 коммитов. По Engineering Workflow дубль только из-за второго PR не заводится, а подходящая открытая Issue переиспользуется, поэтому цикл продолжается в этой же Issue.

Исходные данные зафиксированы

$ for d in . frontend backend docs specs; do
    git -C "$d" merge-base --is-ancestor origin/main origin/develop && echo "$d ok"; done
. ok
frontend ok
backend ok
docs ok
specs ok

Типы коммитов origin/main..origin/develop посчитаны и внесены в таблицу — feat присутствует в frontend и backend, то есть ожидается minor; в остальных трёх только patch-уровень. Окончательный выбор остаётся за release-it.

Issue готова к исполнению; сам релиз в рамках текущей задачи по очистке Git не выполнялся.

Issue переоформлена под следующий релизный цикл по линейной модели. ## Что изменилось в постановке | Было (старая модель) | Стало | | --- | --- | | `release/X.Y.Z` от `develop` → ff в `main` → back-merge PR `main → develop` | `release/X.Y.Z → develop` (ff) → `develop → main` (ff) → тег | | AC: «Each release commit is returned to `develop` through a non-squashed, non-rebased `main -> develop` PR» | AC: «Инвариант `origin/main` — предок `origin/develop` сохранён; отдельного sync-PR не создаётся» | | Голые ожидания без исходного состояния | Таблица `main`/тег/`develop`/ahead/типы коммитов на 2026-10-17 | Старая формулировка была недостижима: требуемый шаг отменён в `#34`, а merge-коммиты запрещены настройками всех пяти репозиториев. Заголовок изменён с «release all current develop changes» на «release current develop state by the linear git model» — прежний не отличал этот цикл от предыдущего, уже выпущенного. ## Почему Issue не закрыта и не заменена новой Предыдущий цикл (`v0.2.2`/`v1.1.0`/`v2.1.0`/`v0.1.4`) выпущен и его теги на месте — это зафиксировано в разделе «Контекст». Но результат Issue в title — «выпустить текущее состояние `develop`» — остаётся недостигнутым: `develop` снова впереди на 3/19/23/11/14 коммитов. По Engineering Workflow дубль только из-за второго PR не заводится, а подходящая открытая Issue переиспользуется, поэтому цикл продолжается в этой же Issue. ## Исходные данные зафиксированы ``` $ for d in . frontend backend docs specs; do git -C "$d" merge-base --is-ancestor origin/main origin/develop && echo "$d ok"; done . ok frontend ok backend ok docs ok specs ok ``` Типы коммитов `origin/main..origin/develop` посчитаны и внесены в таблицу — `feat` присутствует в `frontend` и `backend`, то есть ожидается minor; в остальных трёх только patch-уровень. Окончательный выбор остаётся за `release-it`. Issue готова к исполнению; сам релиз в рамках текущей задачи по очистке Git не выполнялся.
codex-bot commented 2026-10-18 18:09:05 +03:00
Author
Owner
Copy Link
Copy Source

Релизный цикл выполнен

Выпущен по линейной модели release/X.Y.Z → develop --ff--> main --> tag, без back-merge.

repo версия main = develop тег PR stage 1 PR stage 2
main 0.2.2 → 0.2.3 7ab1b74 v0.2.3 #39 #40
frontend 1.1.0 → 1.2.0 ed811e8 v1.2.0 frontend#93 frontend#94
backend 2.1.0 → 2.2.0 b20080a v2.2.0 backend#114 backend#115
docs 0.1.4 → 0.1.5 24ad250 v0.1.5 docs#53 docs#54
specs 0.1.4 → 0.1.5 ab24ccc v0.1.5 specs#53 specs#54

Версии выбраны release-it по принятым Conventional Commits: minor там, где есть feat (frontend, backend), остальные patch. Все merge — fast-forward-only, merge-коммитов нет. Инвариант origin/main — предок origin/develop выполняется во всех пяти; main, develop и SHA тега совпадают, версия в package.json равна тегу.

Образы

Опубликованы в Nexus по тегу (image.yml), оба run success:

образ digest
wealthledger/frontend:1.2.0 sha256:37e1cb2d56dce796c30306a4652df8f9cb90883f72d6a993bed3d80ef91e846c
wealthledger/backend:2.2.0 sha256:e4ba91a89bc9162f067cb055a03b07682ecc00274f54044f02bacfcca9026fef

Deployment bundle

Вынесен в отдельную Issue deploy#7, PR deploy#8 (release.env на новую пару). Проверено: OpenAPI contract backend 2.2.0 идентичен входному snapshot frontend 1.2.0; новых migrations нет. Остаётся проверка на disposable Linux и создание тега bundle.

Известное отклонение

frontend#94 и backend#115 слиты с force_merge. Причина: на релизном SHA помимо зелёных PR-проверок есть второй набор статусов от push-события в develop, где verify падает на Sonar Quality Gate (verify.yml, шаг Analyze develop with SonarQube). Это не регрессия релизного коммита — тот же gate валил push и до релиза (frontend run 1404 на eefdde2, backend run 1429 на 32622c1). PR-gates (commits, security, verify) на обоих были success. Sonar разбирается отдельно.

Issue закрывается: цикл завершён. Следующий релиз — новая Issue.

## Релизный цикл выполнен Выпущен по линейной модели `release/X.Y.Z → develop --ff--> main --> tag`, без back-merge. | repo | версия | `main` = `develop` | тег | PR stage 1 | PR stage 2 | | --- | --- | --- | --- | --- | --- | | `main` | 0.2.2 → 0.2.3 | `7ab1b74` | `v0.2.3` | #39 | #40 | | `frontend` | 1.1.0 → 1.2.0 | `ed811e8` | `v1.2.0` | frontend#93 | frontend#94 | | `backend` | 2.1.0 → 2.2.0 | `b20080a` | `v2.2.0` | backend#114 | backend#115 | | `docs` | 0.1.4 → 0.1.5 | `24ad250` | `v0.1.5` | docs#53 | docs#54 | | `specs` | 0.1.4 → 0.1.5 | `ab24ccc` | `v0.1.5` | specs#53 | specs#54 | Версии выбраны release-it по принятым Conventional Commits: minor там, где есть `feat` (frontend, backend), остальные patch. Все merge — fast-forward-only, merge-коммитов нет. Инвариант `origin/main` — предок `origin/develop` выполняется во всех пяти; `main`, `develop` и SHA тега совпадают, версия в `package.json` равна тегу. ## Образы Опубликованы в Nexus по тегу (`image.yml`), оба run `success`: | образ | digest | | --- | --- | | `wealthledger/frontend:1.2.0` | `sha256:37e1cb2d56dce796c30306a4652df8f9cb90883f72d6a993bed3d80ef91e846c` | | `wealthledger/backend:2.2.0` | `sha256:e4ba91a89bc9162f067cb055a03b07682ecc00274f54044f02bacfcca9026fef` | ## Deployment bundle Вынесен в отдельную Issue deploy#7, PR deploy#8 (`release.env` на новую пару). Проверено: OpenAPI contract backend `2.2.0` идентичен входному snapshot frontend `1.2.0`; новых migrations нет. Остаётся проверка на disposable Linux и создание тега bundle. ## Известное отклонение `frontend#94` и `backend#115` слиты с `force_merge`. Причина: на релизном SHA помимо зелёных PR-проверок есть второй набор статусов от `push`-события в `develop`, где `verify` падает на Sonar Quality Gate (`verify.yml`, шаг `Analyze develop with SonarQube`). Это не регрессия релизного коммита — тот же gate валил `push` и до релиза (frontend run 1404 на `eefdde2`, backend run 1429 на `32622c1`). PR-gates (`commits`, `security`, `verify`) на обоих были `success`. Sonar разбирается отдельно. Issue закрывается: цикл завершён. Следующий релиз — новая Issue.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Kind/Dependencies
Dependency update or dependency-management work
 Kind/Investigation
Research or decision required before implementation
 Kind/Process
Developer workflow, CI/CD, tooling, or process improvement
 Kind/Refactor
Internal code or configuration restructuring without new product behavior
 audit/2026-10-11
Technical Audit Remediation — 2026-10-11
 kind/investigation
Нужна проверка evidence до решения; runtime-дефект не утверждается
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Medium
3
The priority is medium
Priority
Low
4
The priority is low
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
Status
Abandoned
3
Somebody has started to work on this but abandoned work
No labels Kind/Process
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
codex-bot hermes-agent ksv741 publisher-bot renovate-bot
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: WealthLedger/main#30