Add new blog post for versioning - #195
Merged
guanzhousongmicrosoft merged 4 commits intoOct 2, 2026
Merged
Conversation
alaye-ms
force-pushed
the
users/alaye/versioning-blog
branch
from
October 1, 2026 13:05
f61455c to
7e1cd76
Compare
alaye-ms
force-pushed
the
users/alaye/versioning-blog
branch
from
October 1, 2026 13:05
7e1cd76 to
0b3b41f
Compare
guanzhousongmicrosoft
left a comment
guanzhousongmicrosoft
left a comment
Member
There was a problem hiding this comment.
Please add RC1 install instructions and a feedback link. The installer defaults to 0.117, so users need to explicitly select RC1.
| - 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. |
Member
There was a problem hiding this comment.
Could we lead with “1.0-RC1 is available for testing”? The current wording sounds like 1.0 GA is out with LTS.
Comment on lines
+22
to
+27
| 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. |
Member
There was a problem hiding this comment.
Are these support and upgrade commitments agreed on? I’d keep the GA policy separate from the RC1 announcement.
Contributor
Author
There was a problem hiding this comment.
Yes, these were all agreed to as part of RFC-0008. I think this blog post needs to be equal parts announcement and explanation, since we have a confusing and unconventional release pattern.
|
|
||
| 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. |
Member
There was a problem hiding this comment.
Please move this warning near the top: testing only, no ongoing RC1 maintenance, and no supported RC upgrades. Use a fresh instance each time.
xgerman
requested changes
Oct 2, 2026
|
|
||
| ## Definition of support | ||
|
|
||
| DocumentDB will publish one new major version each year. The major versions are on branches such as `release/v3`. |
There was a problem hiding this comment.
s/will/aims to/g (or you can use plans to)
|
|
||
| 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. |
|
|
||
| ## 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. |
There was a problem hiding this comment.
I would rewrite this more along the lines like once we release a new minor version the previous version becomes deprecated and all users are required to update. There will be no long-term support of a minor version.
| 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. |
xgerman
approved these changes
Oct 2, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.