Feature Request
Description of Problem:
The generator currently assumes there is exactly one "current" production version of the Rune DSL at any point in time. This assumption is baked into both halves of the dependency-update-to-release pipeline:
.github/renovate.json watches a single rosetta.dsl.version Maven property on the default branch and raises one dependency-update PR stream against it..github/workflows/release.yml reads rosetta.dsl.version from pom.xml, derives the release tag from that single value, and only permits a real release to be cut from main.
Rune DSL is planning to support two production versions concurrently. Once that happens, the generator's pipeline has no way to track or release against the second line — Renovate will only ever propose updates toward whichever DSL version main's pom.xml happens to point at, and the release workflow will refuse to cut a release from anywhere except main.
In Job Story form:
When Rune DSL has two concurrently supported production versions, I want the generator's dependency monitoring and release process to track and publish against both versions independently, so I can give consumers a generator release that matches whichever production DSL version they have adopted, without one line's updates blocking or overwriting the other's.
Potential Solutions:
This assumes the same generator codebase can correctly target both DSL production lines — i.e. nothing about the two lines requires different generator behavior, only a different DSL version to build/test against.
Single branch with dual version properties and a parameterized release
- Keep a single branch (
main). Pin both DSL lines as separate properties in pom.xml, e.g. rosetta.dsl.version.v9 and rosetta.dsl.version.v10, instead of the current single rosetta.dsl.version property.
- Configure Renovate
packageRules to match each property name independently (no baseBranches needed), so the bot raises two separate, correctly-scoped update streams — one per DSL major — both visible on the existing dependencyDashboard.
- Parameterize
release.yml with a "which DSL line to release" input, and have it select the corresponding property when resolving the version to build, tag, and publish. One source tree, two release artifacts.
- Decide how to handle GitHub's single "latest release" designation — e.g.
make_latest: false for the older line — and document both supported version streams in the README so consumers pin the generator version matching their adopted DSL major.
- CI (
ci.yml, build-and-test.yml) ideally runs the test suite against both properties (a small matrix addition) so a change that breaks one line is caught before release, not after.
Considered drawback: this bets that the two DSL lines never need different generator behavior. If that assumption breaks down later, the project would need to retrofit a branch split under pressure rather than having it in place ahead of time. It also means a single bug fix is automatically "live" for both lines as soon as it merges, which is desirable here but would not be true if the lines ever needed independent code paths.
Alternatives Considered
Per-line branch with scoped dependency monitoring and release access
If the two DSL lines turn out to require different generator behavior, fall back to maintaining one long-lived branch per supported line, with main always tracking the forward-looking line and a dedicated branch named after the line that will eventually retire — e.g. 9.x.x, mirroring the maintenance-branch naming rune-dsl itself already uses. The cutover would fork 9.x.x off main at its current state, then advance main's rosetta.dsl.version (and Renovate allowedVersions) to the new line. Renovate would use baseBranches + matchBaseBranches to scope each branch's updates, and the main-only guard in release.yml would become an allow-list of production branches.
This avoids the "bet" above, since each line's code can diverge freely, but it roughly doubles ongoing maintenance: bug fixes, dependency bumps unrelated to the DSL, and CI changes all have to be duplicated or cherry-picked across both branches for as long as both lines remain in production. Given the current assumption that one codebase serves both lines, this is not the recommended starting point — it's the fallback if that assumption turns out to be wrong.
Feature Request
Description of Problem:
The generator currently assumes there is exactly one "current" production version of the Rune DSL at any point in time. This assumption is baked into both halves of the dependency-update-to-release pipeline:
.github/renovate.jsonwatches a singlerosetta.dsl.versionMaven property on the default branch and raises one dependency-update PR stream against it..github/workflows/release.ymlreadsrosetta.dsl.versionfrompom.xml, derives the release tag from that single value, and only permits a real release to be cut frommain.Rune DSL is planning to support two production versions concurrently. Once that happens, the generator's pipeline has no way to track or release against the second line — Renovate will only ever propose updates toward whichever DSL version
main'spom.xmlhappens to point at, and the release workflow will refuse to cut a release from anywhere exceptmain.In Job Story form:
Potential Solutions:
This assumes the same generator codebase can correctly target both DSL production lines — i.e. nothing about the two lines requires different generator behavior, only a different DSL version to build/test against.
Single branch with dual version properties and a parameterized release
main). Pin both DSL lines as separate properties inpom.xml, e.g.rosetta.dsl.version.v9androsetta.dsl.version.v10, instead of the current singlerosetta.dsl.versionproperty.packageRulesto match each property name independently (nobaseBranchesneeded), so the bot raises two separate, correctly-scoped update streams — one per DSL major — both visible on the existingdependencyDashboard.release.ymlwith a "which DSL line to release" input, and have it select the corresponding property when resolving the version to build, tag, and publish. One source tree, two release artifacts.make_latest: falsefor the older line — and document both supported version streams in the README so consumers pin the generator version matching their adopted DSL major.ci.yml,build-and-test.yml) ideally runs the test suite against both properties (a small matrix addition) so a change that breaks one line is caught before release, not after.Considered drawback: this bets that the two DSL lines never need different generator behavior. If that assumption breaks down later, the project would need to retrofit a branch split under pressure rather than having it in place ahead of time. It also means a single bug fix is automatically "live" for both lines as soon as it merges, which is desirable here but would not be true if the lines ever needed independent code paths.
Alternatives Considered
Per-line branch with scoped dependency monitoring and release access
If the two DSL lines turn out to require different generator behavior, fall back to maintaining one long-lived branch per supported line, with
mainalways tracking the forward-looking line and a dedicated branch named after the line that will eventually retire — e.g.9.x.x, mirroring the maintenance-branch naming rune-dsl itself already uses. The cutover would fork9.x.xoffmainat its current state, then advancemain'srosetta.dsl.version(and RenovateallowedVersions) to the new line. Renovate would usebaseBranches+matchBaseBranchesto scope each branch's updates, and themain-only guard inrelease.ymlwould become an allow-list of production branches.This avoids the "bet" above, since each line's code can diverge freely, but it roughly doubles ongoing maintenance: bug fixes, dependency bumps unrelated to the DSL, and CI changes all have to be duplicated or cherry-picked across both branches for as long as both lines remain in production. Given the current assumption that one codebase serves both lines, this is not the recommended starting point — it's the fallback if that assumption turns out to be wrong.