diff --git a/_scala3-reference/changed-features/pattern-bindings.md b/_scala3-reference/changed-features/pattern-bindings.md
index 307ff6387c..be13cee3ac 100644
--- a/_scala3-reference/changed-features/pattern-bindings.md
+++ b/_scala3-reference/changed-features/pattern-bindings.md
@@ -9,7 +9,7 @@ next-page: /scala3/reference/changed-features/pattern-matching
 In Scala 2, pattern bindings in `val` definitions and `for` expressions are
 loosely typed. Potentially failing matches are still accepted at compile-time,
 but may influence the program's runtime behavior.
-From Scala 3.1 on, type checking rules will be tightened so that warnings are reported at compile-time instead.
+From Scala 3.2 on, type checking rules will be tightened so that warnings are reported at compile-time instead.
 
 ## Bindings in Pattern Definitions
 
@@ -18,7 +18,7 @@ val xs: List[Any] = List(1, 2, 3)
 val (x: String) :: _ = xs   // error: pattern's type String is more specialized
                             // than the right-hand side expression's type Any
 ```
-This code gives a compile-time warning in Scala 3.1 (and also in Scala 3.0 under the `-source future` setting) whereas it will fail at runtime with a `ClassCastException` in Scala 2. In Scala 3.1, a pattern binding is only allowed if the pattern is _irrefutable_, that is, if the right-hand side's type conforms to the pattern's type. For instance, the following is OK:
+This code gives a compile-time warning in Scala 3.2 (and also earlier Scala 3.x under the `-source future` setting) whereas it will fail at runtime with a `ClassCastException` in Scala 2. In Scala 3.2, a pattern binding is only allowed if the pattern is _irrefutable_, that is, if the right-hand side's type conforms to the pattern's type. For instance, the following is OK:
 ```scala
 val pair = (1, true)
 val (x, y) = pair
@@ -28,7 +28,7 @@ want to decompose it like this:
 ```scala
 val first :: rest = elems   // error
 ```
-This works in Scala 2. In fact it is a typical use case for Scala 2's rules. But in Scala 3.1 it will give a warning. One can avoid the warning by marking the right-hand side with an `@unchecked` annotation:
+This works in Scala 2. In fact it is a typical use case for Scala 2's rules. But in Scala 3.2 it will give a warning. One can avoid the warning by marking the right-hand side with an `@unchecked` annotation:
 ```scala
 val first :: rest = elems: @unchecked   // OK
 ```
@@ -43,7 +43,7 @@ val elems: List[Any] = List((1, 2), "hello", (3, 4))
 for (x, y) <- elems yield (y, x) // error: pattern's type (Any, Any) is more specialized
                                  // than the right-hand side expression's type Any
 ```
-This code gives a compile-time warning in Scala 3.1 whereas in Scala 2 the list `elems`
+This code gives a compile-time warning in Scala 3.2 whereas in Scala 2 the list `elems`
 is filtered to retain only the elements of tuple type that match the pattern `(x, y)`.
 The filtering functionality can be obtained in Scala 3 by prefixing the pattern with `case`:
 ```scala
@@ -59,4 +59,4 @@ Generator      ::=  [‘case’] Pattern1 ‘<-’ Expr
 
 ## Migration
 
-The new syntax is supported in Scala 3.0. However, to enable smooth cross compilation between Scala 2 and Scala 3, the changed behavior and additional type checks are only enabled under the `-source future` setting. They will be enabled by default in version 3.1 of the language.
+The new syntax is supported in Scala 3.0. However, to enable smooth cross compilation between Scala 2 and Scala 3, the changed behavior and additional type checks are only enabled under the `-source future` setting. They will be enabled by default in version 3.2 of the language.