Topics discussed:

• The release build and the CI build are quite different processes, and the release one is awkward to automate. Rather than fight it, the approach taken was to build it by hand: a separate releases branch holding the historical release content, mixed into the CI build by the existing GitHub Action. The IG Builder then does the rest for free — the published version says it is the current published version in its permanent home, and links to a directory of published versions alongside the CI build.
• An IG release has to nominate a FHIR version, which sits badly here, because ViewDefinition carries its own fhirVersion and is otherwise fairly FHIR-version agnostic. Two different things are being conflated: the FHIR version the spec is built against, and the version a particular ViewDefinition applies to — and those need not match. The FHIRPath IG has a nominal FHIR version in its package-list.json but manages to suppress it in the history display, which was suggested as the way out.
• Someone pushed back on versioning altogether: if the group commits to not breaking things, why play the multi-version game at all, given the misery of maintaining docs and fixes across versions — and there are still deployments stuck on FHIR 0.8 that simply can't migrate. The counter-argument was that you cannot honestly promise never to break, FHIR packages and consumers need a stable URL that won't move underneath them, and an IG has to colour inside the ecosystem's lines to stay intuitive.
• The middle ground: label elements and features with the version they arrived in, and note deprecations the same way — much as JSON Schema splits its test suite into folders per draft. That leaves a real problem. If a runner doesn't recognise a new keyword it will just ignore it and quietly return a different result, so a view may need to declare that it requires a runner at 2.1 or later. And a ViewDefinition isn't self-describing — hand someone one on its own and nothing tells them what version of anything it assumes.
• The QA report was cleared as a non-blocker. One item looks like an IG publisher bug. The other complains that the spec uses an experimental value set in something that isn't experimental — and the resource types value set genuinely is marked experimental in core FHIR, so there is nothing here to fix.