MariaDB 10.0.9, tentatively the last RC, is almost out. MariaDB 10.0.10 GA is coming shortly after.
I envision all those who is planning to upgrade to 10.0 as soon as it becomes stable, waiting for the GA to throw a switch.
I know the feeling. As a user, I never take anything too new either.
But you are not just users, right? If you are in charge of upgrade, you are superusers, you are smart and cautious, you won’t put it in production just like that, but will try in a staging first. So do it, do it now, it’s already time. You won’t gain much by waiting further; but you’ll most certainly lose something.
Of course you have every right to expect a stable reliable version once it’s called GA, and to be irritated if you encounter a problem, and to blame us for that. But it won’t help you get what you need.
See, there are always bugs, GA or not GA. Most of them won’t affect you, but some might. Nobody can evaluate this soon-to-be-GA product in regard to your tasks and goals better than you.
There won’t be huge changes between the RC and GA. Install now, try, report while it is still RC — and there is a good chance you’ll get the fix in time, and possibly even a better one than you’d have if you reported after-GA: as everyone knows, the further after GA, the less intrusive (and sometimes less efficient) bugfixes become. Also, keep in mind that we always give higher priority to external bug reports comparing to those of comparable severity, but filed from inside.
Why do I care whether you install or not?
There is the everlasting argument whether it’s right or wrong to release early and let the community try out the product before it ripens. Ironically, quality control people are often the most fierce antagonists. Why, is it not a good thing when somebody helps you “do your job”?
Well, most testers are still marginally humans. While we know better than anybody that there are always bugs, it’s still excruciating when somebody finds one after you; and much more so if this somebody is an external user. Besides, for many testers the cool part of the job is hunting and finding fancy crashes, while working with external reports is a mundane routine.
So, all in all, we begin to rationalize. The argument that QC often comes up with is that external bugs are mostly a useless waste of time, they are unimportant, badly reported, and so on. When higher authorities are involved, the rationale sounds more elegant, something like not wishing to burden the community with doing the dirty work. But underneath, it’s all the same, trying to keep appearances.
I think at the end it works against the quality of the product.
Maybe I’m just lucky, or maybe MariaDB users are the best, but I’m getting really great bug reports from the community all the time. Some are nearly perfect right away, many require additional work and clarification, and yes, it takes time to process them, and — oh yes — I feel very bad about every bug that we hadn’t caught before the users did; but anyway, this contribution is invaluable, because it represents the real users’ problems, and because, no matter how hard we work on testing the product, we can’t compete with the whole universe of users who have all imaginable (and often unimaginable) kinds of workflow, data, environments, combinations of the third-party software, you name it.