The standing development → beta release-train PRs have been open and conflicting since 2026-08-20. Sync to Beta keeps them open and succeeds on every push — but it cannot resolve a conflict, so the train stalls and development drifts.
The conflict is structural, not incidental
Each branch maintains its own version line in appinfo/info.xml:
| app |
beta |
development |
| pipelinq |
0.3.2-beta.20260820200556 |
0.3.1-unstable.20260825060716 |
| decidiq |
1.0.2-beta.20260821043705 |
1.0.1-unstable.20260825065559 |
Both branches modify the same line after the merge base, so every train merge collides there by construction. It is not a one-off that a rebase clears.
Everything else merges cleanly — for both apps the conflict is exactly one file and exactly one line.
Why it can't be resolved from a side branch
The obvious fix — a branch carrying the resolved merge — is rejected by the gate:
Pull requests to beta must come from 'development', 'main', or a 'hotfix/*' branch.
Your branch 'release/merge-development-into-beta' does not match any allowed pattern.
That gate is correct and I am not proposing to weaken it. But it means the conflict has to be resolved on development, and development cannot adopt beta's -beta version without corrupting its own -unstable line. The two constraints are mutually exclusive as things stand.
(integriq's train merged fine today — its conflict happened to be a comment in release.yml, not the version line. So this is latent everywhere and only bites when the version lines diverge.)
Suggested fix: a merge driver for the version line
Declare appinfo/info.xml as merge=ours on the release branches via .gitattributes, so a train merge keeps the target branch's version and takes everything else:
appinfo/info.xml merge=ours
with the driver registered in the workflow that performs the merge:
git config merge.ours.driver true
The target branch's version is the correct one to keep: beta owns its -beta line and the release workflow bumps from there. Taking development's would move beta backwards — which is exactly the failure mode already recorded in #562.
Alternatives considered
- Resolve by hand each time. What happens today — which is to say, it does not happen, and the train sits for a week.
- Allow
release/* → beta in the gate. Weakens a protection that exists for good reasons.
- Single shared version line across branches. A much larger change to the release model.
Affected now
- pipelinq #1242 (development 98 ahead of beta)
- decidiq #813 (development 61 ahead)
Both still open and conflicting.
The standing
development → betarelease-train PRs have been open and conflicting since 2026-08-20.Sync to Betakeeps them open and succeeds on every push — but it cannot resolve a conflict, so the train stalls and development drifts.The conflict is structural, not incidental
Each branch maintains its own version line in
appinfo/info.xml:0.3.2-beta.202608202005560.3.1-unstable.202608250607161.0.2-beta.202608210437051.0.1-unstable.20260825065559Both branches modify the same line after the merge base, so every train merge collides there by construction. It is not a one-off that a rebase clears.
Everything else merges cleanly — for both apps the conflict is exactly one file and exactly one line.
Why it can't be resolved from a side branch
The obvious fix — a branch carrying the resolved merge — is rejected by the gate:
That gate is correct and I am not proposing to weaken it. But it means the conflict has to be resolved on
development, anddevelopmentcannot adopt beta's-betaversion without corrupting its own-unstableline. The two constraints are mutually exclusive as things stand.(integriq's train merged fine today — its conflict happened to be a comment in
release.yml, not the version line. So this is latent everywhere and only bites when the version lines diverge.)Suggested fix: a merge driver for the version line
Declare
appinfo/info.xmlasmerge=ourson the release branches via.gitattributes, so a train merge keeps the target branch's version and takes everything else:with the driver registered in the workflow that performs the merge:
git config merge.ours.driver trueThe target branch's version is the correct one to keep:
betaowns its-betaline and the release workflow bumps from there. Taking development's would move beta backwards — which is exactly the failure mode already recorded in #562.Alternatives considered
release/*→betain the gate. Weakens a protection that exists for good reasons.Affected now
Both still open and conflicting.