Topaz Video Needs More Disciplined Release Governance
I am still running Topaz Video 1.2.1 for production work. Curious as to why?
Not because I do not want new models, or dislike progress or change, but because later versions have not earned my trust.
I have no objection to new features. The problem is releasing half-ready software as if it is safe for production use.
That is a release-governance failure.
If a version is still being worked out, call it a beta. Users understand what that means. It means Topaz is tinkering, and people doing serious work should wait. Everything since 1.2.1 is a beta whether Topaz says so or not. Take a look:
- 1.2.1 — Production baseline. Last trusted build.
- 1.3.x — No material production gain. Hold at 1.2.1.
- 1.4.0 — Starlight/Neuroserver introduced. New failure points. No-go.
- 1.5.0 — Partial cleanup. Neuroserver/Starlight issues remain. No-go.
- 1.6.x — Model/platform expansion. Reports of failures, jitter, crashes, memory issues, workflow regressions. No-go.
- 1.7 beta — Correct lane for experimental work. Keep it beta until stable.
We are sick of installing what looks like a stable public release, only to find out afterward that it was basically an experiment that broke things people were actively using.
This major lack of internal discipline in the dev pipeline has become the pattern at Topaz. A version finally becomes stable enough for real work. Then Topaz pushes out a major change, breaks existing workflows, and users have to comb through forum threads to figure out what the release notes did not plainly tell them: whether the update is safe to inject into their workflow.
Then, instead of stopping everything long enough to restore trust, Topaz seems to drift toward the next shiny object. Some of the damage gets cleaned up, but too much of what was broken remains unresolved while attention shifts to the next big interface change or backend experiment.
Topaz develops software like a trad-husband does home improvement: start one project, leave half of it unfinished, create three new problems, then get excited about tearing into the next room before fixing the damage from the last one.
That is not release governance. That is churn. It is undisciplined and unprofessional.
This is not the first time this has happened.
During the old TVAI cycle, I stayed on 3.5.4 for roughly a year, from around October 2023 to October 2024, because it was the last version I trusted for production work. I skipped v4.x entirely. By the time I tested 5.2.0.2, the same problem was still there: Topaz had spent an entire year and one full version number changing the interface around while the basic reliability of core functions was left unsettled.
In February 2024, I said:
Stop with the redesigns. Just get what exists fully working and improve the models.
At the time, the problem was UI churn. Now it is major under-the-hood changes, including the Starlight and Neuroserver rollout. The details are different, but the pattern is still the same.
Topaz always responds to individual bugs. That part is great. Staff will say something is known, under investigation, or fixed in a patch. That is useful, but they never address the larger problem: unstable work is being treated as normal release material.
Regressions that break real workflows should stop a release from going out. They should not become forum fodder after users have already installed it.
What we need to hear Topaz say is something like this:
We recognize that recent releases have damaged user confidence in Topaz Video as a tool for production work. We have been fixing individual bugs, but the larger issue is our release process. Some changes were released as normal updates before they were stable enough. Going forward, we will maintain one clearly identified stable version, keep experimental work in beta until it is ready, clearly publish known serious issues, and make rollback easy.
Why can’t you guys designate one current version as stable, put experimental work in beta, clearly tell users which version is safest for production work, publish known serious issues before people install, provide easy rollback capability, and stop making users discover release-breaking problems the hard way?
Topaz Video is not just a demo platform. Many of us use it in real workflows with long queues, deadlines, paid jobs, and machines that cannot be casually disrupted.
We like new models, and innovation is always welcome.
Releasing into the wild what should be labeled as beta software is not welcome.
Please completely overhaul the internal governance of your development and release cycle.
Please designate a stable version — the last one where everything actually worked — and use that as your baseline. If that version is getting too old, that is your signal that you still have a development-priority problem.
Please put experimental work back where it belongs: in beta.
Please stop normalizing regression cycles in public releases.
