diff --git a/developer/releases/2_0/release-notes.md b/developer/releases/2_0/release-notes.md
index e0a5751d..a428a121 100644
--- a/developer/releases/2_0/release-notes.md
+++ b/developer/releases/2_0/release-notes.md
@@ -68,7 +68,7 @@ Note: if the user has custom Template VMs (i.e. other than the default template,
 
 #### From Qubes R1 to R2 beta1
 
-If you're already running Qubes Release 1, you don't need to reinstall, it's just enough to update the packages in your Dom0 and the template VM(s). This procedure is described [here?](/doc/upgrade-to-r2/).
+If you're already running Qubes Release 1, you don't need to reinstall, it's just enough to update the packages in your Dom0 and the template VM(s). This procedure is described [here](/doc/upgrade-to-r2/).
 
 #### From Qubes R1 or R2 Beta 1 to R2 beta2
 
diff --git a/developer/releases/4_0/release-notes.md b/developer/releases/4_0/release-notes.md
index b80a1959..f58eb0b9 100644
--- a/developer/releases/4_0/release-notes.md
+++ b/developer/releases/4_0/release-notes.md
@@ -9,7 +9,7 @@ title: Qubes R4.0 release notes
 New features since 3.2
 ----------------------
 
-* Core management scripts rewrite with better structure and extensibility, [API documentation](https://dev.qubes-os.org/projects/qubes-core-admin/en/latest/)
+* Core management scripts rewrite with better structure and extensibility, [API documentation](https://web.archive.org/web/20230128102821/https://dev.qubes-os.org/projects/qubes-core-admin/en/latest/)
 * [Admin API](/news/2017/06/27/qubes-admin-api/) allowing strictly controlled managing from non-dom0
 * All `qvm-*` command-line tools rewritten, some options have changed
 * Renaming VM directly is prohibited, there is GUI to clone under new name and remove old VM
diff --git a/developer/releases/version-scheme.md b/developer/releases/version-scheme.md
index a96f9ca6..f241a70a 100644
--- a/developer/releases/version-scheme.md
+++ b/developer/releases/version-scheme.md
@@ -71,7 +71,7 @@ When enough progress has been made, we announce the first stable release, e.g.
 `3.0.0`. This is not only a version but an actual release. It is considered
 stable, and we commit to supporting it according to our [support
 schedule](/doc/supported-releases/). Core components are branched at this
-moment, and bug fixes are backported from the master branch. Please see [help,
+moment, and bug fixes are backported from the main branch. Please see [help,
 support, mailing lists, and forum](/support/) for places to ask questions about
 stable releases. No major features or interface incompatibilities are to be
 included in this release. We release bug fixes as patch releases (`3.0.1`,
@@ -173,7 +173,7 @@ We mark each component version in the repository by tag containing
 
 At the release of some release we create branches named like `release2`. Only
 bug fixes and compatible improvements are backported to these branches. These
-branches should compile. All new development is done in `master` branch. This
+branches should compile. All new development is done in `main` branch. This
 branch is totally unsupported and may not even compile depending on maintainer
 of repository.