Questions and concerns about the pace of development

[anfragment]

Hi @leaanthony and team,

Thanks for all the work going into the project.

I've noticed the pace of the project has picked up significantly, seemingly with the help of LLM-assisted tools. v3.1.0, released 6 days after v3.0.0, modifies or deletes 213 of the 1,314 existing non-test Go files in v3 and adds ~68k lines. That's roughly a third of the v3 codebase. Most of the v3.1.0 changelog entries are from @taliesin-ai, and some PRs are very large. For example, #6531 added 231k lines across 830 files and was merged only five hours after it was opened.

I'd like to understand the process behind that pace:

1. How are engineering quality standards maintained at this volume? For example, does a human maintainer read every PR? How do you decide when automated review is enough? Is @taliesin-ai an automated LLM bot operated by you, or by a third party?
2. How does the process make sure bugs show up during review rather than in production apps built on Wails? I took a cursory look, and it doesn't seem like PRs get automated e2e testing on any platform. The e2e probe in v3/tests/purego/e2e appears to be run by hand, doesn't cover Windows, and only has 8 scenarios on macOS and Linux. That doesn't seem enough given the breadth of Linux configurations users have in the wild. Is there some manual or automated QA happening behind the scenes?

Answers would help projects building on Wails (including us at Irbis) decide which versions to adopt and how much testing to do on their side. These questions come from a place of respect for the work you do, but right now I'm concerned about the sustainability of this approach and the potential regressions for users of apps built on Wails.

Thanks!

[leaanthony]

Thanks for writing this up. These are fair questions.

Who is taliesin-ai?

It's my agent. I operate it and I'm accountable for what it does. It isn't a third party.

Is the code just generated and pushed in hours?

No. The headline numbers make it look that way, but a lot of the work behind v3.1.0 happened beforehand on dev branches. PureGo and Wake are good examples. By the time something like #6531 merged, it wasn't new code that had been written and pushed that afternoon. Merging was the last step of a longer process, and the five-hour gap between opening and merging doesn't reflect how long the work had been in progress. Wake was already part of the beta releases and purego was part of the v2 codebase - we just chose to bring it back because purego is a lot more stable now.

Is a human reading every PR?

Not line by line on every one. Review is tiered. Humans look hardest at the risky and core areas. For everything else, the gate is automated review plus tests. I won't pretend a human read 231k lines in five hours.

Why work this way?

Wails has a huge backlog because there isn't enough human time to get through it, and that's before the steady flow of new issues and PRs. Most of us aren't on this full time. Human review also doesn't guarantee quality, least of all when the reviewer is stretched thin. So we're automating as much as we can, and we think that gets issues addressed faster and raises quality significantly. It's a new road for us, and we don't expect to get it right straight away.

Why did v3.1.0 follow v3.0.0 so quickly?

It took nearly four years to get v3 released, because there was a lot of work behind the scenes exploring different ideas. We have a lot of cool things still to release and we're looking forward to doing so. People question when progress is slow, and people question when progress is fast. So we're doing timed releases with what we have. That's the cadence we announced. The v3.0.0 post said nightlies would make fixes available sooner, with weekly releases giving a regular cadence of tested updates. The v3.1.0 post marks the start of the weekly feature releases. The release blog post has the details. v3.2.0 will be tagged this weekend as per the cadence.

How are bugs caught before release?

• Automated checks on PRs and branches.
• Nightly releases for early access. They preview the next weekly, so anyone who wants the newest changes can try them and report problems early.
• Weekly releases, which have had a week of nightlies behind them. Weeklies are what @latest resolves to.
• Hotfix patch releases for urgent problems.

You're right that there are gaps. The e2e probe in v3/tests/purego/e2e is run manually, it has no Windows coverage, and it has only 8 scenarios across macOS and Linux. We can definitely do better there.

For Irbis and other downstream projects

@latest follows the weekly releases. Nightlies are opt-in by exact tag and are meant for early access. As with any open source project, Wails comes with no guarantees, so we'd recommend running your own tests against whatever version you adopt. We'll keep working on quality on our side, and you're best placed to verify what matters for your product. If you find regressions, please file them. With this setup they get fixed quickly.

Your concerns about sustainability and regressions are reasonable, and I don't think they're settled yet. We'll learn from how this goes and adjust.

---

For fun, here's a screenshot of internal tooling being used to manage the project 😄