ChainSafe / ChainSafe/canton-extending-mainnet
[P2-E9.4] Upgrade-compatibility gate for daml/ changes
- Dominant language
- Shell
- Stars
- 0
- Forks
- 0
- Avg merge
- 22h 58m
- Merged PRs (30d)
- 1
Description
There is no automated upgrade-compatibility check on this fork, and nothing has ever run one against the dedicated-synchronizer work.
No `daml/*/daml.yaml` carries an `upgrades:` key (checked all 25), so `daml build` performs no upgrade typecheck. `DamlCompatibilityCheck` does not exist as a job or an sbt task; `git grep DamlCompatibility` hits only `NoDamlCompatibilityCheck`, a scalatest opt-out tag. The real mechanism is `workflow_dispatch` on `build.yml` with the `daml_base_version` input (`.github/workflows/build.yml:20-36`, documented at `DEVELOPMENT.md:384-388`).
This matters because the fork already shipped one package-identity defect: `feat/dedicated-sync` carries `splice-amulet 0.1.22` with hash `3db32c99...` while upstream's `0.1.22` is `fb10433a...`. A participant that vetted upstream can never accept the fork build. PR #23 fixes it by bumping to 0.1.23, but nothing prevents a recurrence.
Also record the rule that adding an `Optional` field is irreversible once populated: `ValueTranslator.scala:211-213` rejects downgrading an `Optional` holding `Some`, so the first `MemberTraffic` with `operator = Some op` can never be read by a component resolving to the older package version.
**Key files:** `.github/workflows/build.yml`, `daml/dars.lock`, `DEVELOPMENT.md`
**Acceptance criteria:**
- [ ] Any PR touching `daml/` runs the `daml_base_version` compatibility check before merge
- [ ] A package-version bump is required whenever a shipped Daml package changes, enforced or documented
- [ ] The `Optional` downgrade rule is written down where a Daml author will see it
**Depends on:** none
**Epic:** ChainSafe/canton-extending-mainnet#72
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with .github/workflows/build.yml:20-36 and DEVELOPMENT.md:384-388 to understand the existing daml_base_version workflow_dispatch path, then inspect daml/dars.lock and the Daml package changes. Review ValueTranslator.scala:211-213 for the Optional downgrade rule. Done means PRs touching daml/ receive the compatibility check, shipped package changes require a version bump, and the downgrade rule is documented for Daml authors.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, scala
- Domain
- build-system, ci-cd, documentation, release
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100