The latest updates on your projects. Learn more aboutVercel for Git ↗︎

size-limit report 📦

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 76.38%. Comparing base(6bb8983) to head(6b07e1b).
Report is 174 commits behind head on main.

@@            Coverage Diff             @@##             main    #2182      +/-   ##==========================================- Coverage   77.05%   76.38%   -0.67%==========================================  Files          84       87       +3       Lines        2157     2439     +282       Branches      555      637      +82     ==========================================+ Hits         1662     1863     +201- Misses        382      460      +78- Partials      113      116       +3

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report?Share it here.

As for canary releases, I think it's overcomplicated for the Lingui case. The flow withmain as stable andnext as unstable future major release works pretty well and there is no need to publish every merge to themain branch. Most of the time, we simply don't have anext branch at all.

Interesting how flow with changesets should look like where next merged into main.

Good question. Probably this could cause problems and the first stable release of the new major version should be done manually to make sure everything is ready for release. I am also still thinking about a separate workflow for publishing that should be triggered manually. This gives more control over the process.

As for canary releases, I think it's overcomplicated for the Lingui case. The flow with main as stable and next as unstable future major release works pretty well and there is no need to publish every merge to the main branch. Most of the time, we simply don't have a next branch at all.

This is debatable, but I don’t think it’s complicated. In fact, it’s even simpler because it removes the need for branching entirely—it’s a shift in how we think about releases.

Thenext branch actually introduces a problem: once it’s created, you now havetwo branches to maintain and keep in sync whenever something lands inmain. The real issue here is the branching topology.

Instead, a more streamlined approach could be:

• main → Always has the latest changes, including breaking ones.
• v5 → A snapshot of the repo when we decided to start the next major version.
• v4,v3, etc. → Older stable versions.

With this model, if a hotfix is needed for the latest stable version, you apply it there and cherry-pick it tomain if necessary—without having to constantly syncnext withmain.

This also benefits contributors, as they always work with the latest changes by default, without needing to be explicitly directed to anext branch.

And as for canary releases, it's really just about automation—fresh changes are published automatically so contributors and early adopters can start using them right away.