panates / rman / 36707581411

95%

push

github

feat(version): version.cascade, a floor under a group's release width

`cascade` was carrying two different questions and only answering one of them.

The ecosystem's half is right and stays where it is: whether a caret range
already carries a patch to a dependent, and whether a floor left behind is a
broken install, are facts about npm. What it cannot answer is whether a
repository wants **one number across its whole product** - a release identity
decision - and there was nowhere to state it, because `cascade` is a
`protected abstract` method no config can reach.

Measured on panates/sqb: 17 packages, `group: true`, every one published at
6.0.10 ever since it moved off rman 1.x's `version.unified: true` - and a `fix:`
in two of them planned `6.0.10 -> 6.0.11` for those two and `no-change` for the
other fifteen. Correct on ranges, and the wrong answer for that repository: the
divergence is permanent, since a group's next baseline is the highest version
among its members, and every README and issue there is written in terms of one
number. It is also what `group`'s own documentation promised - "one repo-wide
version line" - which the cascade table quietly made true of majors only.

**A floor, never a ceiling.** `cascadeFor` adds the declared answer to the
technologies' and takes the widest, so a repository may ask for a wider release
than npm requires and cannot ask for a narrower one. The two mistakes are not
symmetric: too wide republishes a package that did not need it, too narrow
leaves a dependent's published range floor wrong. So `cascade: changed` still
reaches dependents on a patch and the whole group on a major.

**Not a safety valve, and documented as not being one.** A change that can break
a dependent is a `feat:` or a `feat!:`; renumbering the dependent does not make
a behavioural break safe. The lever for that is the bump size.

Two mistakes found by measuring what I had written:

- A clause reading a declared cascade where there is no bum... (continued)

2991 of 3277 branches covered (91.27%)

Branch coverage included in aggregate %.

81 of 83 new or added lines in 2 files covered. (97.59%)

18071 of 19050 relevant lines covered (94.86%)

206.24 hits per line