ACEsuit / mace / 33484773395
75%

DEFAULT BRANCH: develop
Ran
Jobs 1
Files 68
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 74.498% (+0.07%) from 74.429%
33484773395

push

github

web-flow 
Say where a change belongs while v0.3 and v1 coexist (#1699)

Two stacks will live side by side for the length of the v1 rewrite, and
contributors currently have no way to know which one their change belongs
in. Work aimed at the wrong tree is work that gets deleted, so the answer
has to be reachable before someone writes it.

CONTRIBUTING.md gives the routing. Three branches and no others: main
carries releases and is cut by merging develop into it, develop is where
v0.3 is developed, and mace-reforge is the rewrite. No maintenance branch
is needed because main already holds the released state and stays on v0.3
until v1 is released.

The legacy package is frozen on mace-reforge, not on develop. That is what
makes the routing possible: develop keeps taking bug fixes and self
contained features, while the rewrite measures itself against a tree that
does not move. When the rewrite finishes, whatever is new on develop is
migrated into v1, then mace-reforge merges back into develop and develop
into main for the v1 release.

Bug fixes are always accepted, on develop for v0.3 and on mace-reforge for
v1. A new feature should be built in v1 wherever that is possible, because
a feature added to v0.3 has to be ported: someone reimplements it against
the new architecture and proves it still computes the same numbers. Where
v1 is genuinely not an option, and today that is usually because the stack
is still being scaffolded, v0.3 accepts the feature if it is self-contained
in its own directory and tested on numbers rather than on the absence of
errors. Those numbers are what makes the migration verifiable.

Changes to core behaviour or to shared files are not accepted against v0.3
at all. They cannot cross as a unit, so they have to be re-decided against
the new architecture, and doing them twice is the only outcome.

The toolchain section states what CI enforces today rather than what the
config files imply: one pre-commit run excluding tests/, .github/, docs/,
R... (continued)

8971 of 12042 relevant lines covered (74.5%)

0.74 hits per line

Coverage Regressions

Lines Coverage ∆ File
35
77.11
4.16% modules/lora.py
Jobs
ID Job ID Ran Files Coverage
1 33484773395.1 68
74.5
GitHub Action Run
Source Files on build 33484773395