Despite my best efforts, Viper has seen a few regressions in the last few releases.

Unfortunately, this is to be expected not just with major changes but with minor changes as well due to the complexity of the code and the tons of untested side effects that people often rely on as features.

The fear of breaking existing features has been a significant blocker for some of the improvements I planned and still plan to make for this library.

To prevent future regressions, I'm calling for testers from the community who would help test changes and experimental features before they become generally available.

I don't have a formal or complete process in mind (yet), but the general idea is to hide every major change behind feature flags if possible and ask a specific group of users to do some tests with their own applications for a period of time. If they don't expect any regressions, the change would be released to everyone (i.e. the feature flag removed).

Ideally, this would be a large pool of users from the community with a wide range of usage patterns, so we can share the load and spot regressions of exotic use cases as well.

If you are interested in becoming a tester, please leave a comment here. I also encourage you to share any ideas or things we could look for during these testing periods.

I'd like to brainstorm a few ideas about the process and then start implementing as soon as possible. Hopefully, this will speed up development in the future.

You can also help by spreading the news: if you know a Viper power user, let them know about this thread.

FAQ

Why not just write more unit tests?

I've been doing that for years and I'm still not catching all regressions.

Some of the use cases are so exotic, I just don't think about them.

Some of them just don't appear in my test cases.

This isn't ideal, but until test coverage and general code complexity can improve, we need some manual testers.