Author: Tyler Hannan
Date: October 31, 2019
Originally posted on the Fauna blog.

If you have monitored our release cadence closely over the last several months, you will have seen that we have substantially increased our velocity. As we shifted our focus with FaunaDB to be a cloud-based offering, it provided freedom in release schedule and we’ve taken advantage of that.

Of course, there are a series of common ‘descriptors’ of software releases that carry weight across the industry. Unfortunately, each of these terms carries its own baggage based on your prior experience and understanding of software release schedules.

We’d like to clarify what versioning, and naming, means for our users when they use FaunaDB. Keep in mind that there are multiple ways to use our products (web console, direct endpoint, Javascript driver, Java driver, Scala driver, Golang driver, etc..) As such, much of the complexity that lies within our versioning and release schemes are opaque to our users. But...sharing our perspective and approach is important when ensuring clarity.

Release Cadence & Numbering

In general, we intend to release monthly. This can be more, or less, frequent as the complexities of managing a globally distributed, consistent, multi-API datastore are several. However, a frequent release schedule ensures we are bringing the features that you, our users, desire (and sometimes demand) to market more frequently while also ensuring stability.

We have broadly adopted Semantic Versioning (semver) for our release and adhere to the principles that:

• a MAJOR version is where we make incompatible API changes
• a MINOR version is where we add functionality in a backwards compatible manner
• a PATCH version is where we make backwards compatible bug fixes

Or, perhaps:

• a MAJOR version is where we create awesome features that might require work to update your application if you want to benefit from them. But, no rush, they are there when you are ready.
• a MINOR version is awesome features for free! (all disclaimers apply) little work, new features, much win.
• a PATCH version is where stability improves, you may not ‘see’ a difference but we’ll put all the internals changes in release notes.

With that said, flexibility is key and a feature may slip into a PATCH if necessary but we commit to maintaining backwards compatibility in the manner identified above.

General Availability (GA)

We get it, we release often. We also get it that changing your production code can be onerous. But, take heart, we face the same challenges and requirements ourselves daily. When we do push a release to cloud and drivers as GA, our commitment is that it will be stable, simple to consume, and compatible with previous versions.

A ‘breaking change’ (for Fauna) is one that requires you to do work to adopt the new driver version. If we break existing apps this is the most serious category of bug we will ever face.

Preview

Similarly, there are API features that we believe are important, that we have designed in partnership with our community which we are excited about. We’d love to have people from various backgrounds review our work in various emotional states and share their feedback in detail. These ‘preview’ features represent our current point-of-view on implementation and are a glimpse into the new use cases the community desires.

Some preview features require us to introduce breaking changes or fundamentally rework the API. Since, sometimes our initial idea was just not so great and it has to be improved/simplified. Typically these breaking changes are driven by our community's feedback. We aren’t perfect, yet...but we want to better each release.

Experimental

As mentioned FaunaDB appears to some as an API and some as a web console (and hopefully both). For those who use the console frequently, there are some exciting features that we have been experimenting with for which we would love you, but we need your feedback.

If you are the sort of human who enjoys seeing what we are dreaming about from a UI/UX perspective, knows that things break and that’s sad but how we learn, and that excites you...or maybe you like to see our dreams translated in a user interface? Well, our dreams (aka experimental features) end up in our web console. If you feel like playing with them and sharing your feedback, that would be immensely valuable to us.

End-of-Life (EOL)

Speedy releases shouldn’t mean constant, meaningless upgrades to maintain the ability to get support from ourselves or the community. As we approach the next major release (at time of this writing 3.0) we will support each major release of our product for 12 months from the release date, and we actively maintain the last minor release of the most recent major branch. So, for instance, as we working on 3.x.x we will maintain 2.latest.x.

In addition, we recognise that -- at some point -- it will become necessary to retire features (particularly at the API level) and as that time approaches we will document and share our approach more broadly.

Conclusion

At some point, in the not too distant future, we will write this up in proper legal terms and put on the website and in support agreements. However, sharing in the language of a human was an important first step.

Thank you for building your application on FaunaDB and, most importantly, for trusting us with your feedback.