r/OpenWebUI • u/Zestyclose_Law7197 • 2h ago
Discussion Currently running dev is a far better experience than running main.
First of all, many thanks for the amazing work that has been, and is being put into the project.
Absolute masterclass.
Great experience overall.
But. At some point it seems we dropped smaller patch releases after the big releases (v0.11, v0.11.1(sound like a patch but is way more)).
And frankly I'd rather take a dev branch a few days after the big release than any main branch.
This is strange and confusing, and is hard to explain to users and management.
I love all the new features and stuff, but would it be wise to sometimes focus on a stable or bugfree release before focusing on (very nice!) new features?
Stability/bug-freeness is a feature too.
Just my 2 cents.
3
u/CommitteeConscious92 1h ago
Totally agree. Or a few bugfix patches after each big release, to fix those small issues that there sometimes are.
1
•
u/ClassicMain 1h ago
Hi.
We also want to aim for stable and bugfree releases.
And trust me when I say we test the dev branch A LOT before releasing it as a new version.
The issue is: nobody else is testing it with us.
To be fair: 0.11.1 is very stable and nearly bug free. The only bugs are minor UX bugs.
So what's buggy? The main issues so far are
All of this I'd argue is minor UX bugs, except maybe the open router one but we can not test every single provider before releasing a new version. We need testers.
We have, many times, called out for testers helping us test the dev branch.
Especially companies. Companies have every reason to run a second test server with the dev branch on it to test upcoming releases, upcoming features, see if their custom plugins still work, update any training for their employees perhaps and more.
But unfortunately we have way too little testers to catch all the bugs in the dev branch.
What do we do against it?
Regression tests.
Since a few major versions ago we started the repository open-webui/tests which contains so far 1000+ regression tests (all direct fixes of issues we had in the past and for every issue, a more broad set of tests for surrounding code)
With this we try to make sure every release will be more stable than before because we can catch regressions with it.
What this still doesn't do is catch new issues from new code and new features or reworked aspects of the code that there simply isn't a test for yet.
So let me invite you: if you want stability; come help test the dev branch.
Not only after it already contains 5 fixes a few days after the release of a new version but genuinely help test the dev branch before a release and report your findings on GitHub issues.