diff --git a/src/guide/migration/async-components.md b/src/guide/migration/async-components.md
index 6a6b6fa4a8..20ccb4b482 100644
--- a/src/guide/migration/async-components.md
+++ b/src/guide/migration/async-components.md
@@ -30,7 +30,7 @@ const asyncPage = {
 }
 ```
 
-## Current Syntax
+## 3.x Syntax
 
 Now, in Vue 3, since functional components are defined as pure functions, async components definitions need to be explicitly defined by wrapping it in a new `defineAsyncComponent` helper:
 
@@ -52,7 +52,7 @@ const asyncPageWithOptions = defineAsyncComponent({
 })
 ```
 
-Another change that has been made from v2 is that the `component` option is now renamed to `loader` in order to accurately communicate that a component definition cannot be provided directly.
+Another change that has been made from 2.x is that the `component` option is now renamed to `loader` in order to accurately communicate that a component definition cannot be provided directly.
 
 ```js{4}
 import { defineAsyncComponent } from 'vue'
diff --git a/src/guide/migration/custom-directives.md b/src/guide/migration/custom-directives.md
index cb8c815056..7e80d040e3 100644
--- a/src/guide/migration/custom-directives.md
+++ b/src/guide/migration/custom-directives.md
@@ -9,7 +9,7 @@ Here is a quick summary of what has changed:
 
 For more information, read on!
 
-## Previous Syntax
+## 2.x Syntax
 
 In Vue 2, custom directives were created by using the hooks listed below to target an element’s lifecycle, all of which are optional:
 
@@ -35,7 +35,7 @@ Vue.directive('highlight', {
 
 Here, in the initial setup for this element, the directive binds a style by passing in a value, that can be updated to different values through the application.
 
-## Current Syntax
+## 3.x Syntax
 
 In Vue 3, however, we’ve created a more cohesive API for custom directives. As you can see, they differ greatly from our component lifecycle methods even though we’re hooking into similar events. We’ve now unified them like so:
 
diff --git a/src/guide/migration/events-api.md b/src/guide/migration/events-api.md
index bc3c89e3da..3d963a3df6 100644
--- a/src/guide/migration/events-api.md
+++ b/src/guide/migration/events-api.md
@@ -10,9 +10,9 @@ types:
 
 `$on`, `$off` and `$once` instance methods are removed. Vue instances no longer implement the event emitter interface.
 
-## Previous Syntax
+## 2.x Syntax
 
-In v2, Vue instance could be used to trigger handlers attached imperatively via the event emitter API (`$on`, `$off` and `$once`). This was used to create _event hubs_ to create global event listeners used across the whole application:
+In 2.x, Vue instance could be used to trigger handlers attached imperatively via the event emitter API (`$on`, `$off` and `$once`). This was used to create _event hubs_ to create global event listeners used across the whole application:
 
 ```js
 // eventHub.js
diff --git a/src/guide/migration/fragments.md b/src/guide/migration/fragments.md
index b6490ea95b..bd68409a7b 100644
--- a/src/guide/migration/fragments.md
+++ b/src/guide/migration/fragments.md
@@ -4,7 +4,7 @@
 
 In Vue 3, components now have official support for multi-root node components, i.e., fragments!
 
-## Previous Syntax
+## 2.x Syntax
 
 In 2.x, multi-root components were not supported and would emit a warning when a user accidentally created one. As a result, many components are wrapped in a single `<div>` in order to fix this error.
 
@@ -19,7 +19,7 @@ In 2.x, multi-root components were not supported and would emit a warning when a
 </template>
 ```
 
-## Current Syntax
+## 3.x Syntax
 
 In 3.x, components now can have multiple root nodes! However, this does require developers to explicitly define where attributes should be distributed.
 
diff --git a/src/guide/migration/functional-components.md b/src/guide/migration/functional-components.md
index 0da35ca96f..f9ddeea83b 100644
--- a/src/guide/migration/functional-components.md
+++ b/src/guide/migration/functional-components.md
@@ -4,7 +4,7 @@
 
 In terms of what has changed, at a high level:
 
-- Performance gains from v2 for functional components are now negligible in v3, so we recommend just using stateful components
+- Performance gains from 2.x for functional components are now negligible in 3.x, so we recommend just using stateful components
 - Functional components can only be created using a plain function that receives `props` and `context` (i.e., `slots`, `attrs`, `emit`)
 - **DEPRECATED:** `functional` attribute on single-file component (SFC) `<template>` is deprecated
 - **DEPRECATED:** `{ functional: true }` option in components created by functions is deprecated
@@ -22,9 +22,9 @@ However, in Vue 3, the performance of stateful components has improved to the po
 
 As a result, the only remaining use case for functional components is simple components, such as a component to create a dynamic heading. Otherwise, it is recommended to use stateful components as you normally would.
 
-## Previous Syntax
+## 2.x Syntax
 
-Using the `<dynamic-heading>` component, which is responsible for rendering out the appropriate heading (i.e., `h1`, `h2`, `h3`, etc.), this could have been written as a single-file component in v2 as:
+Using the `<dynamic-heading>` component, which is responsible for rendering out the appropriate heading (i.e., `h1`, `h2`, `h3`, etc.), this could have been written as a single-file component in 2.x as:
 
 ```js
 // Vue 2 Functional Component Example
@@ -56,7 +56,7 @@ export default {
 </script>
 ```
 
-## Current Syntax
+## 3.x Syntax
 
 ### Components Created by Functions
 
@@ -82,7 +82,7 @@ export default GreetingMessage
 
 ### Single File Components (SFCs)
 
-In v3, the performance difference between stateful and functional components has been drastically reduced and will be insignificant in most use cases. As a result, the migration path for developers using `functional` on SFCs is to remove the attribute. No additional work required.
+In 3.x, the performance difference between stateful and functional components has been drastically reduced and will be insignificant in most use cases. As a result, the migration path for developers using `functional` on SFCs is to remove the attribute. No additional work required.
 
 Using our `<dynamic-heading>` example from before, here is how it would look now.
 
diff --git a/src/guide/migration/introduction.md b/src/guide/migration/introduction.md
index 91322fb8cf..f1fee91bcd 100644
--- a/src/guide/migration/introduction.md
+++ b/src/guide/migration/introduction.md
@@ -22,7 +22,7 @@ Some of the new features to keep an eye on in Vue 3 include:
 
 ### Breaking
 
-The following consists a list of breaking changes from v2:
+The following consists a list of breaking changes from 2.x:
 
 - **keyCode support as `v-on` modifiers.** For more information, [see in-depth explanation](/guides/migration/keycodes.html)
 
diff --git a/src/guide/migration/keycode-modifiers.md b/src/guide/migration/keycode-modifiers.md
index cbb42b3d59..d78bca1cf9 100644
--- a/src/guide/migration/keycode-modifiers.md
+++ b/src/guide/migration/keycode-modifiers.md
@@ -7,7 +7,7 @@ Here is a quick summary of what has changed:
 - **BREAKING**: Using numbers, i.e. keyCodes, as `v-on` modifiers is no longer supported
 - **BREAKING**: `config.keyCodes` is no longer supported
 
-## Previous Syntax
+## 2.x Syntax
 
 In Vue 2, `keyCodes` were supported as a way to modify a `v-on` method.
 
@@ -35,7 +35,7 @@ Vue.config.keyCodes = {
 <input v-on:keyup.f1="showHelpText" />
 ```
 
-## Current Syntax
+## 3.x Syntax
 
 Since [`KeyboardEvent.keyCode` has been deprecated](https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/keyCode), it no longer makes sense for Vue 3 to continue supporting this as well. As a result, it is now recommended to use the kebab-case name for any key you want to use as a modifier.
 
diff --git a/src/guide/migration/render-function-api.md b/src/guide/migration/render-function-api.md
index 0cb97d733a..787976af44 100644
--- a/src/guide/migration/render-function-api.md
+++ b/src/guide/migration/render-function-api.md
@@ -14,7 +14,7 @@ For more information, read on!
 
 ## Render Function Argument
 
-### Previous Syntax
+### 2.x Syntax
 
 In 2.x, the `render` function would automatically receive the `h` function (which is a conventional alias for `createElement`) as an argument:
 
@@ -27,7 +27,7 @@ export default {
 }
 ```
 
-### Current Syntax
+### 3.x Syntax
 
 In 3.x, `h` is now globally imported instead of being automatically passed as an argument.
 
@@ -44,7 +44,7 @@ export default {
 
 ## Render Function Signature Change
 
-### Previous Syntax
+### 2.x Syntax
 
 In 2.x, the `render` function automatically received arguments such as `h`.
 
@@ -57,7 +57,7 @@ export default {
 }
 ```
 
-### Current Syntax
+### 3.x Syntax
 
 In 3.x, since the `render` function no longer receives any arguments, it will primarily be used inside of the `setup()` function. This has the added benefit of gaining access to reactive state and functions declared in scope, as well as the arguments passed to `setup()`.
 
@@ -75,13 +75,14 @@ export default {
     }
 
     // return the render function
-    return () => h(
-      'div',
-      {
-        onClick: increment
-      },
-      state.count
-    )
+    return () =>
+      h(
+        'div',
+        {
+          onClick: increment
+        },
+        state.count
+      )
   }
 }
 ```
@@ -90,7 +91,7 @@ For more information on how `setup()` works, see our [Composition API Guide](/gu
 
 ## VNode Props Format
 
-### Previous Syntax
+### 2.x Syntax
 
 In 2.x, `domProps` contained a nested list within the VNode props:
 
@@ -106,7 +107,7 @@ In 2.x, `domProps` contained a nested list within the VNode props:
 }
 ```
 
-### Current Syntax
+### 3.x Syntax
 
 In 3.x, the entire VNode props structure is flattened. Using the example from above, here is what it would look like now.
 
diff --git a/src/guide/migration/slots-unification.md b/src/guide/migration/slots-unification.md
index 9ab65eb68a..5a99e9b5da 100644
--- a/src/guide/migration/slots-unification.md
+++ b/src/guide/migration/slots-unification.md
@@ -2,7 +2,7 @@
 
 ## Overview
 
-This change unifies normal and scoped slots in v3.
+This change unifies normal and scoped slots in 3.x.
 
 Here is a quick summary of what has changed:
 
@@ -11,9 +11,9 @@ Here is a quick summary of what has changed:
 
 For more information, read on!
 
-## Previous Syntax
+## 2.x Syntax
 
-When using the render function, i.e., `h`, v2 used to define the `slot` data property on the content nodes.
+When using the render function, i.e., `h`, 2.x used to define the `slot` data property on the content nodes.
 
 ```js
 // 2.x Syntax
@@ -30,9 +30,9 @@ In addition, when referencing scoped slots, they could be referenced using the f
 this.$scopedSlots.header
 ```
 
-## Current Syntax
+## 3.x Syntax
 
-In v3, render functions will have a `slots` option where they can be defined instead.
+In 3.x, render functions will have a `slots` option where they can be defined instead.
 
 ```js
 // 3.x Syntax
@@ -58,4 +58,4 @@ this.$slots.header
 
 A majority of the change has already been shipped in 2.6. As a result, the migration can happen in one step:
 
-1. Replace all `this.$scopedSlots` occurrences with `this.$slots` in v3.
+1. Replace all `this.$scopedSlots` occurrences with `this.$slots` in 3.x.
diff --git a/src/guide/migration/treeshaking.md b/src/guide/migration/treeshaking.md
index 05d2a49ba4..20178038d9 100644
--- a/src/guide/migration/treeshaking.md
+++ b/src/guide/migration/treeshaking.md
@@ -1,6 +1,6 @@
 # Global API Treeshaking
 
-## Previous Syntax
+## 2.x Syntax
 
 If you’ve ever had to manually manipulate DOM in Vue, you might have come across this pattern:
 
@@ -20,22 +20,22 @@ import { MyComponent } from './MyComponent.vue'
 
 test('an async feature', async () => {
   const wrapper = shallowMount(MyComponent)
-  
+
   // execute some DOM-related tasks
 
   await wrapper.vm.$nextTick()
 
-// run your assertions
+  // run your assertions
 })
 ```
 
-`Vue.nextTick()` is a global API exposed directly on a single Vue object – in fact, the instance method `$nextTick()` is just a handy wrapper around `Vue.nextTick()` with the callback’s `this` context automatically bound to the current Vue instance for convenience. 
+`Vue.nextTick()` is a global API exposed directly on a single Vue object – in fact, the instance method `$nextTick()` is just a handy wrapper around `Vue.nextTick()` with the callback’s `this` context automatically bound to the current Vue instance for convenience.
 
-But what if you’ve never had to deal with manual DOM manipulation, nor are you using or testing async components in our app? Or, what if, for whatever reason, you prefer to use the good old `window.setTimeout()` instead? In such a case, the code for `nextTick()` will become dead code – that is, code that’s written but never used. And dead code is hardly a good thing, especially in our client-side context where every kilobyte matters. 
+But what if you’ve never had to deal with manual DOM manipulation, nor are you using or testing async components in our app? Or, what if, for whatever reason, you prefer to use the good old `window.setTimeout()` instead? In such a case, the code for `nextTick()` will become dead code – that is, code that’s written but never used. And dead code is hardly a good thing, especially in our client-side context where every kilobyte matters.
 
-Module bundlers like [webpack](https://webpack.js.org/) support [tree-shaking](https://webpack.js.org/guides/tree-shaking/), which is a fancy term for “dead code elimination.” Unfortunately, due to how the code is written in previous Vue versions, global APIs like `Vue.nextTick()` are not tree-shakeable and will be included in the final bundle regardless of where they are actually used or not. 
+Module bundlers like [webpack](https://webpack.js.org/) support [tree-shaking](https://webpack.js.org/guides/tree-shaking/), which is a fancy term for “dead code elimination.” Unfortunately, due to how the code is written in previous Vue versions, global APIs like `Vue.nextTick()` are not tree-shakeable and will be included in the final bundle regardless of where they are actually used or not.
 
-## Current Syntax
+## 3.x Syntax
 
 In Vue 3, the global and internal APIs have been restructured with tree-shaking support in mind. As a result, the global APIs can now only be accessed as named exports for the ES Modules build. For example, our previous snippets should now look like this:
 
@@ -65,7 +65,7 @@ test('an async feature', async () => {
 })
 ```
 
-Calling `Vue.nextTick()` directly will now result in the infamous `undefined is not a function` error. 
+Calling `Vue.nextTick()` directly will now result in the infamous `undefined is not a function` error.
 
 With this change, provided the module bundler supports tree-shaking, global APIs that are not used in a Vue application will be eliminated from the final bundle, resulting in an optimal file size.
 
@@ -73,13 +73,12 @@ With this change, provided the module bundler supports tree-shaking, global APIs
 
 These global APIs in Vue 2.x are affected by this change:
 
-* `Vue.nextTick`
-* `Vue.observable` (replaced by `Vue.reactive`)
-* `Vue.version`
-* `Vue.compile` (only in full builds)
-* `Vue.set` (only in compat builds)
-* `Vue.delete` (only in compat builds)
-
+- `Vue.nextTick`
+- `Vue.observable` (replaced by `Vue.reactive`)
+- `Vue.version`
+- `Vue.compile` (only in full builds)
+- `Vue.set` (only in compat builds)
+- `Vue.delete` (only in compat builds)
 
 ## Internal Helpers
 
@@ -103,9 +102,9 @@ export function render() {
 }
 ```
 
-This essentially means the `Transition` component only gets imported when the application actually makes use of it. In other words, if the application doesn’t have any `<transition>` component, the code supporting this feature will not be present in the final bundle. 
+This essentially means the `Transition` component only gets imported when the application actually makes use of it. In other words, if the application doesn’t have any `<transition>` component, the code supporting this feature will not be present in the final bundle.
 
-With global tree-shaking, the user only “pay” for the features they actually use. Even better, knowing that optional features won't increase the bundle size for applications not using them, framework size has become much less a concern for additional core features in the future, if at all. 
+With global tree-shaking, the user only “pay” for the features they actually use. Even better, knowing that optional features won't increase the bundle size for applications not using them, framework size has become much less a concern for additional core features in the future, if at all.
 
 ::: warning Important
 The above only applies to the [ES Modules builds](/guide/installation.html#explanation-of-different-builds) for use with tree-shaking capable bundlers - the UMD build still includes all features and exposes everything on the Vue global variable (and the compiler will produce appropriate output to use APIs off the global instead of importing).
@@ -153,7 +152,7 @@ module.exports = {
 
 This will tell webpack to treat the Vue module as an external library and not bundle it.
 
-If your module bundler of choice happens to be [Rollup](https://rollupjs.org/), you basically get the same effect for free, as by default Rollup will treat absolute module IDs (`'vue'` in our case) as external dependencies and not include them in the final bundle. During bundling though, it might emit a [“Treating vue as external dependency”](https://rollupjs.org/guide/en/#warning-treating-module-as-external-dependency) warning, which can be suppressed with the `external` option: 
+If your module bundler of choice happens to be [Rollup](https://rollupjs.org/), you basically get the same effect for free, as by default Rollup will treat absolute module IDs (`'vue'` in our case) as external dependencies and not include them in the final bundle. During bundling though, it might emit a [“Treating vue as external dependency”](https://rollupjs.org/guide/en/#warning-treating-module-as-external-dependency) warning, which can be suppressed with the `external` option:
 
 ```js
 // rollup.config.js
diff --git a/src/guide/migration/v-model.md b/src/guide/migration/v-model.md
index 3721638f77..1feafb2035 100644
--- a/src/guide/migration/v-model.md
+++ b/src/guide/migration/v-model.md
@@ -21,9 +21,9 @@ In 2.2 we introduced the `model` component option that allows the component to c
 
 With Vue 3, the API for two-way data binding is being standardized in order to reduce confusion and to allow developers more flexibility with the `v-model` directive.
 
-## Previous Syntax
+## 2.x Syntax
 
-In v2, using a `v-model` on a component was an equivalent of passing a `value` prop and emitting an `input` event:
+In 2.x, using a `v-model` on a component was an equivalent of passing a `value` prop and emitting an `input` event:
 
 ```html
 <ChildComponent v-model="pageTitle" />
@@ -87,9 +87,9 @@ For convenience, we had a shorthand for this pattern with the .sync modifier:
 <ChildComponent :title.sync="pageTitle" />
 ```
 
-## Current Syntax
+## 3.x Syntax
 
-In v3 `v-model` on the custom component is an equivalent of passing a `modelValue` prop and emitting an `update:modelValue` event:
+In 3.x `v-model` on the custom component is an equivalent of passing a `modelValue` prop and emitting an `update:modelValue` event:
 
 ```html
 <ChildComponent v-model="pageTitle" />
@@ -130,7 +130,7 @@ This also serves as a replacement to `.sync` modifier and allows us to have mult
 
 ### `v-model` modifiers
 
-In addition to v2 hard-coded `v-model` modifiers like `.trim`, now v3 supports custom modifiers:
+In addition to 2.x hard-coded `v-model` modifiers like `.trim`, now 3.x supports custom modifiers:
 
 ```html
 <ChildComponent v-model.capitalize="pageTitle" />