Something out of the ordinary is happening today: we’re renaming our upcoming MongoDB release to 3.0. Version numbers are usually set well in advance on a product roadmap, and we’ve already put out 6 release candidates under the 2.8 moniker, so I’m sure some eyebrows are being raised right about now. I’m going to explain the reasoning behind this change, starting with a discussion of our versioning scheme.

At MongoDB, we use a versioning system composed of three components. Consider the version number 2.6.3. Two of those components are purely technical in their meaning.The rightmost number (3) is a revision number, denoting fixes for issues, which are always backwards compatible. The middle number (6) is a release series identifier, which we increment as we release new features; these may break backwards-compatibility, but not necessarily.

That leaves the leftmost number, the ‘2’ in 2.6.3. This number is not a technical designation; it corresponds to an overall phase of MongoDB as a product. In fact, the most accurate description of this number is that we increment it when our community tells us we’re entering a new phase.

To date, MongoDB has gone through three phases:

0.x: Science Project. Non-relational databases had little traction, but we were convinced that developers would jump at the chance to build their applications without the contortions required by existing data stores.

1.x: Early Adopters. Fully half of the features now present in MongoDB did not yet exist, and there were many growing pains to endure. For many teams, the trade-off was worth it, but for others, it was not yet ready to meet their needs.

2.x: Mainstream. MongoDB passed enterprise requirements and was deployed to handle massive data processing loads; customers built clusters housing hundreds of Terabytes of data. MongoDB saw adoption beyond the wildest dreams of our Science Project days, and our ever-growing community demanded: “More features! Better performance! Under more workloads! And easier to manage!”

We’ve done our best to comply, and throughout, we have tried to build a database that can be used in as many places as our users want to deploy it. Now we're ready to herald a new phase of MongoDB: the go-to database for modern application development.

Last summer, we committed to document-level locking, a pluggable storage engine API, and an on-premises version of our automation product known as "Ops Manager". We were well on the way to delivering that feature set, but as ambitious as it was, it would not have been the dawn of a new phase. Then we had a windfall, welcoming the WiredTiger team to MongoDB. Now we are delivering beyond what we expected: our product roadmap is accelerated by the capabilities present in WiredTiger, and by the firepower that that team brings to MongoDB. This potential to leapfrog our prior release plan is game-changing.

Feedback on the release candidates from our beta users and community members showed that '2.8' was now a stale reference for something that had become much bigger. "This isn't an incremental release," they said, "it is a step-function release."

This is the kind of feedback a team dreams of hearing. We've decided to act on what you're telling us, and give this release a number appropriate for its impact.

Our team is hard at work readying MongoDB 3.0. Thank you for your continued support -- we’re looking forward to meeting, and hopefully exceeding, your expectations.

To learn more about what's new in MongoDB 3.0, download the white paper below.