Review of 2022, support-cycle announcements and release dates

Hey everyone! We hope you’re doing well and while we did wish everyone on our social channels, our blog visitors didn’t get a good enough wish, so here we go – Happy New Year! We hope that everyone has an amazing year ahead. This post is going to be a review of 2022, while also taking a look at the next release and support cycle changes.

If you’re running short on time, here are quick links to the sections in this post:

• Looking back at 2022
• Support cycle
• Where’s my 0.8?

Looking back at 2022

If I were to sum it up, 2022 was a phenomenal year and there’s a lot that has happened internally. We started the year with release 0.7.2 and ended the year with release 0.7.6, releasing features like list pagination, dev/prod modes, authentication and authorization, system metrics and a bunch of new actions.

While all of this has been going on externally, a lot has been happening internally. We spent a very long time re-imagining Skytable and asking ourselves a fundamental question – “What do we want Skytable to be?” The answer will be in what we will ship this year, across multiple releases. “So you’re saying you spent all that time, thinking?” Of course not! I had the utmost privilege to meet with talented individuals in the industry where we discussed problems and spent a lot of time experimenting with ideas – new and old. This has been a lot of work, and I hope to see what this brings in the current and following quarters!

Support Cycle

Firstly, if you’ve been with us from the start, I can’t pay enough gratitude to you for being with us and we hope you know what we’re going to talk about. And, that’s compatibility and support. A database is not something that should force breaking changes every now and then. It’s fundamentally important that any data you store in previous versions be compatible with newer versions without any added overhead. We made this promise through the versioning policy where backwards compatibility for datasets was guaranteed. All data created on some version 0.x.y would be compatible across all 0.x releases. If you moved from say 0.6 to 0.7, then 0.7 would automatically migrate your data from 0.6 to the current version.

We have enforced this across all releases ever since the versioning policy was adopted by the project. But we want to take this further, because upgrading from one major version (per the versioning policy/ RFC 1) to another major version due to API changes is not always easy. As one can expect, and owing to the amount of time it is taking to ship 0.8, a lot of major changes have occurred and some of them are breaking changes to the API surface.

So we want to introduce a new versioning policy (a draft RFC 2 is in the works) called the “Extended Security and Maintenance” or ESM policy and this will supersede the existing versioning policy. This new policy aims to enforce the following:

• Keep the same backwards compatibility guarantees as RFC 1
• But more importantly, continue to release security and maintenance updates to widely deployed versions

This is crucial because widely deployed database versions must be maintained, and especially when upgrades to the deployed systems are impossible due to API changes (or other legacy requirements). So how do we determine which version is widely deployed? The policy outlines this as:

A widely deployed version is any released version in the stable channel which has been available for more than two subsequent quarters, with no new version superseding it in the first quarter

With the 0.7 long running branch being on stable since August 2021 which is about two years, 0.7 is definitely a target for this policy.

But when do we stop supporting a version? The policy outlines this as:

An ESM release is deprecated when it has been more than two subsequent quarters since the release of two new versions in the stable channel.

Let’s think this through an example.

• 0.7 is released and it is widely deployed (i.e it has been more than two quarters since its release and no new database version was released for one quarter)
• 0.8 is released and 0.7 becomes an ESM release
• 0.9 is released, 0.8 becomes an ESM release and 0.7 is now a deprecated ESM release

While we’re drafting the RFC, if you’d like to help us please bump in anytime on Discord!

Where’s my 0.8?

We knew you’d ask and we’re glad you asked! My oh my 0.8, where do I even start? I know, you want to grab a bunch of diskettes and toss them at me, but well, what if an unstable release did the same to your production server? You definitely don’t want that right? (If you do, there’s something very wrong with you 😂)

The ETA game started on October 31, 2022. That’s about three months back and yet, I can’t even see a little 0 or 8! Yeah, I get your frustration and trust me, I’m not enjoying delaying releases either. As I mentioned in an earlier blog post, and in this one too, a lot has been happening! The core parts of the database engine have quite literally been rewritten several times over.

Now, where is my 0.8? No only tell me if you’re going to actually ship it. This is like what, the *infinity-th* time you’re telling me this?

Right you are! Well, then let’s mark the calendar – March 3, 2023. The beta ships on that date. We’ve spent months on this release and we promise you – it’s going to be great. And it better be! We’re up day and night and working on this, and we’re working hard to ship it to you soon.

If you want to chat with the project admins, driver maintainers and our fellow users, the best way to do it is by joining our Discord Server. We also post fresh updates pretty frequently to our Twitter. Well, see you soon and hopefully on a post with the 0.8 release announcement! Love you all, and take care.