• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

ACEsuit / mace / 34324559915
75%

Build:
DEFAULT BRANCH: develop
Ran 09 Sep 2026 08:17AM UTC
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

31 Aug 2026 10:01AM UTC coverage: 74.498%. Remained the same
34324559915

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

Jobs
ID Job ID Ran Files Coverage
1 34324559915.1 09 Sep 2026 08:17AM UTC 68
74.5
GitHub Action Run
Source Files on build 34324559915
  • Tree
  • List 68
  • Changed 0
  • Source Changed 0
  • Coverage Changed 0
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Repo
  • Github Actions Build #34324559915
  • 59ad3a47 on github
  • Prev Build on develop (#34199353688)
  • Next Build on develop (#34680519573)
  • Delete
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc