Background
JBFL config files currently have no version marker. This makes it hard to evolve the format in a breaking way without silently changing behavior for existing users.
Step 1 - introduce JBFL versioning
Add a version header to JBFL files:
The parser would read this header and use it to determine which semantics to apply. Files without a header are treated as jbfl 1.0.0 for backwards compatibility. JBFL gets its own semver, decoupled from the jbeam-edit release version - a major bump signals a breaking change in format semantics.
Step 2 - jbfl 2.0.0: unified match semantics and > combinator
The current property matching has an invisible split hardcoded in the implementation:
- ExactMatch (no cascade):
AutoPad, AlignObjectKeys, AutoPadSubObjects
- PrefixMatch (cascades to descendants):
ComplexNewLine, PreserveNumberFormat, Indent, PadDecimals, PadAmount, TrailingComma
Users cannot control this. The result is that rules like this are required to suppress unwanted cascade:
.*.mainEngine { ComplexNewLine: Force; }
.*.mainEngine.torque[*] { ComplexNewLine: None; } // fight the cascade
jbfl 2.0.0 would introduce a > child combinator. A rule using > applies only at that exact path level - no cascade. Without >, all properties cascade by default. The per-property split disappears.
// jbfl 2.0.0
.* > .mainEngine { ComplexNewLine: Force; AlignObjectKeys: true; }
This also makes it possible to write a single rule covering all top-level config sections without enumerating names:
.* > .* { ComplexNewLine: Force; AlignObjectKeys: true; }
Migration
When jbeam-edit reads a file with // jbfl 1.0.0 (or no header) and jbfl 2.0.0 is available, it warns and offers to run a migration tool. The migration is mechanical:
- Properties moved to
> blocks: AutoPad, AlignObjectKeys, AutoPadSubObjects, ComplexNewLine
- Properties that keep cascading:
PreserveNumberFormat, PadDecimals, PadAmount, Indent, TrailingComma
Mixed rule blocks are split into two separate blocks automatically.
Background
JBFL config files currently have no version marker. This makes it hard to evolve the format in a breaking way without silently changing behavior for existing users.
Step 1 - introduce JBFL versioning
Add a version header to JBFL files:
The parser would read this header and use it to determine which semantics to apply. Files without a header are treated as jbfl 1.0.0 for backwards compatibility. JBFL gets its own semver, decoupled from the jbeam-edit release version - a major bump signals a breaking change in format semantics.
Step 2 - jbfl 2.0.0: unified match semantics and
>combinatorThe current property matching has an invisible split hardcoded in the implementation:
AutoPad,AlignObjectKeys,AutoPadSubObjectsComplexNewLine,PreserveNumberFormat,Indent,PadDecimals,PadAmount,TrailingCommaUsers cannot control this. The result is that rules like this are required to suppress unwanted cascade:
jbfl 2.0.0 would introduce a
>child combinator. A rule using>applies only at that exact path level - no cascade. Without>, all properties cascade by default. The per-property split disappears.This also makes it possible to write a single rule covering all top-level config sections without enumerating names:
Migration
When jbeam-edit reads a file with
// jbfl 1.0.0(or no header) and jbfl 2.0.0 is available, it warns and offers to run a migration tool. The migration is mechanical:>blocks:AutoPad,AlignObjectKeys,AutoPadSubObjects,ComplexNewLinePreserveNumberFormat,PadDecimals,PadAmount,Indent,TrailingCommaMixed rule blocks are split into two separate blocks automatically.