Add new blog post for versioning

blogs/_posts/2026-10-01-versioning.md

@@ -0,0 +1,44 @@
+---
+title: "Long-term support or development? An explanation of DocumentDB's versioning"
+description: A comparison DocumentDB's long-term support builds versus the latests development builds
+date: 2026-10-01
+featured: true
+author: DocumentDB team
+category: documentdb-blog
+tags:
+  - DocumentDB
+  - "1.0"
+  - Release
+  - Version
+---
+
+DocumentDB is releasing version 1.0 with long-term support, splitting from the main development branch that will continue with 1.1 and beyond.
+This is to ensure there is a stable version of the platform for users who don't need the latest features.
+
+This post will also clarify what support really means, describe how we will handle future minor version updates (1.1, 1.2, etc.), and explain when updates to the different tracks will happen.
+
+## The long-term support track
+
+DocumentDB will publish one new major version each year. The major versions are on branches such as `release/v3`. 
+Security fixes will be backported to supported release branches, with new artifacts built until support ends. Other bug fixes will be backported case by case.
+A major version will be supported in this way until three months after the next major version is released.
+
+Backports of security fixes will be added to the LTS version with a patch version bump. For example, a security fix could bump the long-term support branch to v3.0-1, but not v3.1-0.
+The long-term support track will not get any minor updates, only patch updates.
+
+### Release candidates
+
+Release candidates use the `-RC` suffix. For example, a release candidate for version 3 could be tagged `v3.0-RC1`, followed by a final release tag such as `v3.0-0`. After the final release, `release/v3` becomes the supported branch for version 3, while `main` moves on to development for version 4. The previous `release/v2` branch remains supported during its grace period.
+
+## The main development track
+
+Major releases are time-based. Minor releases, however, will continue to be pushed out as they have been before, as development work completes. Instead of backporting, the artifacts on the main development track will be built only when the next minor version releases. In this way, all security and bug fixes will come as a user of the development track rolls forward with the latest minor updates.
+
+## Upgrade paths
+
+DocumentDB will support direct in-place upgrades between consecutive long-term support major versions.
+For example, if you are using v1.0-2, and v2.0-0 is released as part of a new major, there will be instructions for how to update to that next version before v1.0 falls out of support.
+
+There is also a simple path from the current major release to the latest minor release of that same major. This will allow for a simple switch from long-term support to the latest builds.
+
+Release candidates are different. Upgrades from release candidate versions will not be supported. Release candidates use the same extension version as the first full release for that major, so there is no reliable extension upgrade path from an RC to the final release.