10.7.0 Comes As Preview Releases

Written by Written by Kaj Arnö 3 Comments on 10.7.0 Comes As Preview Releases

Now is the time to try out the new candidate features of MariaDB Server 10.7, the next release series of MariaDB! This blog describes how the new preview releases work, and where we need your help as a MariaDB user.

The challenge: Making MariaDB mature quicker

Remember the challenges and visions I described two weeks ago? To address them we launch an experiment with several parallel preview releases of MariaDB Server 10.7 features.

This should solve two challenges mentioned in the blog: giving users early access to new functionality and making releases mature more rapidly through intensive internal testing. Read on.

An early deadline for MariaDB 10.7 features

To test our hypothesis, we set an early deadline for MariaDB Server 10.7 features. While the normal complete MariaDB 10.7 release is planned for the end of October, as usual, the deadline for features was Wednesday 15 September 2021. By this time, any feature wishing to be a candidate for MariaDB 10.7 had to be delivered and pass basic quality assurance.

The candidate features for MariaDB 10.7

By this deadline, nine features had passed the test. They are, in order of MDEV number and including their description:

  1. MDEV-4742 A function for natural sorting of strings
  2. MDEV-4958 UUID data type
  3. MDEV-9245 password reuse prevention plugin
  4. MDEV-12933 Compression provider plugins
  5. MDEV-21130 More precise histograms using JSON for the on-disk format
  6. MDEV-26519 JSON Histograms: improve histogram collection
  7. MDEV-22165 CONVERT TABLE TO PARTITION, and
  8. MDEV-22166 CONVERT PARTITION TO TABLE
  9. MDEV-25015 Custom formatting of strings in MariaDB queries

as well as a bunch of smaller features. A decent collection for three months of work, if you ask me!

“Oh, so all those features are delivered in 10.7.0?“, you may ask. Yes and no. This is where it gets tricky. Let me explain.

Separate binaries for separate features

There is a significant difference in how you access the features of MariaDB 10.7.0-preview from how you did it in 10.6.0-alpha, 10.5.0-alpha, and earlier releases.

The experiment we are conducting here is to let you play with features before they all get merged into one release. That means that each of the features has its own binary package. If you want to test the Python-like sformat function, go for the 10.7.0-mdev-25015-sformat binary. For UUID, use the 10.7.0-mdev-4958-uuid binary.

More work for the end user?

“But wait, that’s more work for me as a MariaDB user!”, you may say. “Why couldn’t you just deliver them all in one release, like before?”.

And you would be right: it might a bit more work for you, if you are interested in more than one feature. But it is for a good cause – by providing feedback on a preview of a feature you can make sure the feature is shaped the way you want and in the final release it will work the way you need.

This was not the case before. We take backward compatibility very seriously and cannot change behaviour of a released feature, as it might adversely affect users that already rely on it. There are no such concerns about previews, so now is the best time to comment if you want your feedback to have an immediate effect.

Your role: Verify that features meet your expectations

Here is where you come in: Check whether 10.7.0 has a feature that you need (I listed all features on top in this blog). Download the preview release that you’re interested in, and try it out! This preview is your chance to make sure that a feature you need really does what you want it to do.

On the download page for 10.7.0, you will see sources in Linux (x86-64 bintar) and source formats only. In contrast to earlier releases (and in contrast to 10.7.1 planned for the end of October), you will have to pick your feature in a drop-down menu:

As you see, there isn’t an exact one-on-one relationship between the feature list and the download packages, for example both “CONVERT” features are in the same package, and there is a “misc features” one that contains the sundry rest of the stuff. But I’m sure you get the gist of it.

Easier access in the days to come

We’re working on making the features more accessible in other formats: Docker images, and binder previews. There also will be blog posts about individual features, in the upcoming days.

What will happen now

Starting today, there will be about six weeks of intensive testing. Internally, and by you, our users.

The features that pass the testing hurdle will then be merged into MariaDB Server 10.7.1.

Starting from 10.7.1, we do not plan to add or change functionality. This is why we are now relying upon you, as a user of MariaDB Server, to use the early access we’re giving you and to tell us if the candidate features should be merged into 10.7.1.

Looking forward to gaining experience from the preview model!

Appendix A: The links

Appendix B: Improving the development process

OK, so I promised to explain why we think the preview model is a good thing for the MariaDB users.

The reason we believe in the preview model is twofold: It removes the congestion of the merge hassle happening just before a release. And it prevents bad apples from causing the whole basket to rot, meaning: if one or more of the features turns out to have serious issues, the feature will not make it into 10.7.1, the first “normal” release of 10.7.

This means there is a second deadline, by which our testers will have to give their stamp of approval for each feature to be merged. It’s hard on the border of foolhardy to unmerge a feature, so why merge unless you’re confident in a feature?

Let me highlight two passages from the Challenges and visions blog, both about making releases mature more rapidly. The first one is about internal testing:

But perhaps it might be possible to compress the time somewhat by doing intensive internal testing before the very first release. Ideally, intensive targeted testing can allow us to fast-forward through early maturity phases, discovering those bugs in days and weeks, not months.

The second one is about early user access:

[..] only users can tell whether we have designed it correctly. It is absolutely crucial to provide early access to new features to be able to discover and correct those problems that no internal testing can find.

Those are now the hypotheses we are putting to test.