Adds the 0.85 versioned docs to websitev2, following the same process used for 0.84 (#1263). - #1292
Adds the 0.85 versioned docs to websitev2, following the same process used for 0.84 (#1263).#1292anuagragith wants to merge 2 commits into
Conversation
Snapshot the docs website for the RNW 0.85 release, following the same process used for 0.84 (PR #1263): - Copy versioned_docs/version-0.84 -> version-0.85 (identical file set) - Copy versioned_sidebars/version-0.84-sidebars.json -> 0.85 - Bump version references (0.84 -> 0.85) in the two docs that carry them: getting-started.mdx and native-platform-getting-started.md - Prepend 0.85 to versions.json -> ["0.85", "0.84", "0.83"] - docusaurus.config.js: lastVersion 0.84 -> 0.85 and prepend 0.85 to onlyIncludeVersions The previous versions (0.84, 0.83) are retained, matching how 0.84 kept 0.83. Note: the support.md lifecycle table is intentionally NOT updated here - it needs the finalized 0.85 release date and the recomputed maintenance / end-of-support dates for the older versions. See the PR description. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
Vineeth (@vineethkuttan) - how should we handle support.md? I intentionally did not touch src/pages/support.md (the version lifecycle / support table) in this PR, because adding the 0.85 row means committing to real dates: the 0.85 release date plus recomputed Maintenance Start / End-of-Support dates for 0.84 and the older versions. Is it okay to use the best-guess placeholder dates now and update them as things become stable? |
Yep ,that works anuagragith. |
|
Hi anuagragith Can you create a sample gh-pages on your forked repo. So, that it will be easy for me to review. This is the one I created for 0.84 release. You can find the powershell script for this in the repo itself. |
Adds the 0.85 (Active/latest) row with placeholder release date 09/10/2026. Cascades per policy: 0.84 -> Maintenance (maint 10/31/2026, EOS 12/31/2026, link to v0.84-stable), 0.82 -> Unsupported. Dates are placeholders to be finalized on actual release. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
Hi Vineeth (@vineethkuttan) - thanks for the guidance on the placeholder dates. I pushed the support.md update ( cd33503b ), please review here when you get a chance. • 0.85 → new Active/ latest row, placeholder release 09/10/2026 (Maint/EOS TBD) Follows the existing date conventions and the 0.84 phase-shift precedent (#1263). Dates are placeholders per your OK. Builds cleanly locally; I'll set up a gh-pages preview next time for a visual review. |
2 participants
Description
Changes
• Copy versioned_docs/version-0.84 → version-0.85 (identical file set, 278 files)
• Copy the sidebar → versioned_sidebars/version-0.85-sidebars.json
• Bump version references 0.84 → 0.85 in the only two docs that carry them: getting-started.mdx and native-platform-getting-started.md
• Prepend 0.85 to versions.json → ["0.85", "0.84", "0.83"]
• docusaurus.config.js : lastVersion 0.84 → 0.85 , and prepend 0.85 to onlyIncludeVersions
• Retains 0.84 and 0.83 (matching how the 0.84 update kept 0.83)
❓Question for reviewers — how should we handle support.md ?
I intentionally did not touch src/pages/support.md (the version lifecycle / support table) in this PR, because adding the 0.85 row means committing to real dates: the 0.85 release date plus recomputed Maintenance Start / End-of-Support dates for 0.84 and the older versions. Is it okay to use the best-guess placeholder dates now and update them as things become stable??
Microsoft Reviewers: Open in CodeFlow