promote: dev → main (alert template: omit empty value line) #97

Merged

admin_emi merged 1 commit from dev into main

2026-07-25 18:19:11 +00:00

admin_emi commented

2026-07-25 18:18:20 +00:00

Owner

Promotes dev → main, deploying to beta (beta.thermograph.org).

Who merges. Centralis, once the required check is green — under the promotion policy main is the agent's call, and a promotion PR left open is worse than one never opened.

Divergence. 1 ahead, 2 behind. 1 commit(s) to carry, but the target has moved on by 2 — a merge commit is required and conflicts are possible
Not fast-forwardable: the target holds 2 commit(s) the source does not. That is the accumulated design of this release chain, not a mistake anyone just made — every promotion merges the source into the target, which creates a merge commit ON THE TARGET that the source never receives, so each promotion widens the gap it just closed. Expect --ff-only to fail with "diverging branches"; the promotion is a merge commit.

Predicted conflicts. None: no file was touched on both sides since the branches parted.

Commits (1).

b32b5841 alerting: don't print a bare "value:" when ValueString is empty (#96)

Merge with a merge commit, not a squash or a fast-forward. main runs ahead of dev from earlier promotions, so --ff-only fails with "diverging branches", and squashing would rewrite the shared history so the next promotion sees every prior commit as new. (Making promotions fast-forward-only is an open question, not current policy — it needs a one-time history reconciliation on the protected branches first.)

Promotes `dev` → `main`, deploying to beta (beta.thermograph.org). **Who merges.** Centralis, once the required check is green — under the promotion policy `main` is the agent's call, and a promotion PR left open is worse than one never opened. **Divergence.** 1 ahead, 2 behind. 1 commit(s) to carry, but the target has moved on by 2 — a merge commit is required and conflicts are possible Not fast-forwardable: the target holds 2 commit(s) the source does not. That is the accumulated design of this release chain, not a mistake anyone just made — every promotion merges the source into the target, which creates a merge commit ON THE TARGET that the source never receives, so each promotion widens the gap it just closed. Expect `--ff-only` to fail with "diverging branches"; the promotion is a merge commit. **Predicted conflicts.** None: no file was touched on both sides since the branches parted. **Commits (1).** - b32b5841 alerting: don't print a bare "value:" when ValueString is empty (#96) **Merge with a merge commit, not a squash or a fast-forward.** `main` runs ahead of `dev` from earlier promotions, so `--ff-only` fails with "diverging branches", and squashing would rewrite the shared history so the next promotion sees every prior commit as new. (Making promotions fast-forward-only is an open question, not current policy — it needs a one-time history reconciliation on the protected branches first.)

admin_emi added 1 commit 2026-07-25 18:18:21 +00:00